У меня не воспроизвелось:

[c0der@xxx ~/awk-crash]$ cat test.conf| ./bad-write-param.awk >bad
[c0der@xxx ~/awk-crash]$ cat test.conf| ./ok-write-param.awk >ok
[c0der@xxx ~/awk-crash]$ cat test.conf| ./ok2-write-param.awk >ok2
[c0der@xxx ~/awk-crash]$ diff -u bad ok 
[c0der@xxx ~/awk-crash]$ diff -u bad ok2
--- bad 2008-07-16 12:06:19 +0700
+++ ok2 2008-07-16 12:06:31 +0700
@@ -24,7 +24,7 @@
 #report_remote_uri_down        = yes                           # yes = create the reports if the remote host is down. no = don't make any reports if the host is down
 
 #@@ mandatory backup fields
-backup_source          = /usr #source 
+backup_source          = /usr #source
 backup_destination     = $HOME/backup
 backup_exclude         = $HOME/backup *.swp *.tmp
 
[c1der@xxx ~/awk-crash]$

gawk-3.1.5-alt3, локаль UTF8

У меня локаль ru_RU.CP1251, ядро 2.6.18-xen-dom0-alt7, glibc-2.5-alt5.

(In reply to comment #2)
> У меня локаль ru_RU.CP1251, ядро 2.6.18-xen-dom0-alt7, glibc-2.5-alt5.

У меня локаль ru_RU.UTF-8, ядро 2.6.18-std-smp-alt7, glibc-2.5.1-alt4

Попробую ещё дома проверить, так ядро свежее и локаль CP1251 как раз.

На 2.6.25-std-def-alt6, glibc-2.5.1-alt5, gawk-3.1.5-alt3 и CP1251 падение воспроизвести не смог.

На glibc-2.5.1-alt5 тоже воспроизводится. Забыл сказать: система x86_64. Получается, что различия только в ядре и, возможно, в архитектуре.

>Забыл сказать: система x86_64.

Ну так это существенно меняет дело!

Если ещё какие-нибудь детали меняют дело, спрашивайте, не стесняйтесь. Что вспомнил - написал.

Ага! Смог воспроизвести:

[coder@pbf64 awk-crash]$ rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE} %{ARCH}\n' gawk glibc 
gawk-3.1.5-alt3 x86_64
glibc-2.5-alt4 x86_64

При этом ядро: 2.6.18-ovz-smp-alt20 и локаль обязательно должна быть однобитная (т.е. при ru_RU.UTF8 не падает, а при C -- падает).

Вот нормальный backtrace:

[coder@pbf64 gawk-3.1.5]$ gdb -q
(gdb) set env LANG=C
(gdb) run -f bad-write-param.awk <test.conf >/dev/null
Starting program: /home/coder/gawk-3.1.5/gawk -f bad-write-param.awk <test.conf >/dev/null
*** glibc detected *** gawk: realloc(): invalid next size: 0x000000000066e700 ***
[skip]
(gdb) bt
#0  0x00002aaaab1783a5 in raise () from /lib64/libc.so.6
#1  0x00002aaaab179730 in abort () from /lib64/libc.so.6
#2  0x00002aaaab1adebb in iswupper () from /lib64/libc.so.6
#3  0x00002aaaab1b2e1e in iswupper () from /lib64/libc.so.6
#4  0x00002aaaab1b5abe in iswupper () from /lib64/libc.so.6
#5  0x00002aaaab1b6cff in realloc () from /lib64/libc.so.6
#6  0x000000000040fc9e in sub_common (tree=<value optimized out>, how_many=1, backdigs=1) at builtin.c:2455
#7  0x0000000000410504 in do_gensub (tree=<value optimized out>) at builtin.c:2560
#8  0x000000000043b7d2 in r_tree_eval (tree=0x65bc40, iscond=0) at eval.c:991
#9  0x0000000000411a23 in do_print (tree=0x65bd00) at builtin.c:1670
#10 0x0000000000439bf4 in interpret (tree=0x65bd00) at eval.c:787
#11 0x0000000000439ad0 in interpret (tree=0x65be00) at eval.c:477
#12 0x000000000043a022 in interpret (tree=0x65bf80) at eval.c:484
#13 0x00000000004398cf in interpret (tree=0x65a970) at eval.c:456
#14 0x0000000000426068 in do_input () at io.c:457
#15 0x000000000042822b in main (argc=3, argv=0x7fff0eaaa9d8) at main.c:595

а как с этой проблемой в 3.1.6?

(In reply to comment #10)
> а как с этой проблемой в 3.1.6?

Когда будет в Сизифе, тогда и проверим.

(В ответ на комментарий №10)
> а как с этой проблемой в 3.1.6?

Также.

Уменьшил test case до:

printf 'backup_source\t= /home/coder\t#source\n' | gawk '{if($0~/(^[[:space:]]*backup_source[[:space:]]*=)([^#]*)?(#.*)?$/){print gensub(/(^[[:space:]]*backup_source[[:space:]]*=)([^#]*)?(#.*)?$/, "\\1 /usr \\3 \\5", "", $0)}}'

gawk-3.1.8-alt1 -> sisyphus:

* Thu Jun 03 2010 Dmitry V. Levin <ldv@altlinux> 3.1.8-alt1
- Updated to 3.1.8 (closes: #4911, #16359).