* Re: [musl] Musl compiled gawk coredumps. How to find out where? @ 2021-09-24 13:48 Érico Nogueira 2021-09-24 14:38 ` Ivo Palli 0 siblings, 1 reply; 8+ messages in thread From: Érico Nogueira @ 2021-09-24 13:48 UTC (permalink / raw) To: musl, Rich Felker On Fri Sep 24, 2021 at 10:02 AM -03, Ivo Palli wrote: > That helped! > > (gdb) backtrace > #0 __restore_sigs (set=set@entry=0x7fff62ee5de0) at > ./arch/x86_64/syscall_arch.h:40 > #1 0x00000000004cf1c4 in raise (sig=sig@entry=6) at > src/signal/raise.c:11 > #2 0x00000000004c96ea in abort () at src/exit/abort.c:11 > #3 0x0000000000452f16 in catchsig (sig=<optimized out>) at main.c:1231 > #4 catchsig (sig=<optimized out>) at main.c:1217 > #5 <signal handler called> > #6 get_meta (p=p@entry=0x7f4d35d74f50 "\260\232\243\001") at > src/malloc/mallocng/meta.h:141 > #7 0x00000000004ca62c in __libc_free (p=0x7f4d35d74f50) at > src/malloc/mallocng/free.c:105 > #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x7f4d35f5c778) at > node.c:492 > #9 0x00000000004456e5 in unref (r=0x7f4d35f5c778) at awk.h:1898 > #10 purge_record () at field.c:360 > #11 0x0000000000445f36 in set_record ( > buf=0x7f4d34f34cfe > "SIZE\t1KB\t192758\t112698119\nSIZE\t4KB\t462090\t1122421206\nSIZE\t16KB\t355596\t3138948391\nSIZE\t64KB\t413028\t13558910172\nSIZE\t256KB\t1014012\t165385758947\nSIZE\t1MB\t2546508\t1346405498466\nSIZE\t10MB\t480844\t1602796961"..., > cnt=25, fw=0x0) at field.c:269 > #12 0x000000000044e765 in inrec (iop=<optimized out>, > errcode=errcode@entry=0x7fff62ee6cb0) at io.c:608 > #13 0x00000000004414f8 in h_interpret (code=<optimized out>) at > interpret.h:1289 > #14 0x0000000000402631 in main (argc=<optimized out>, argv=<optimized > out>) at main.c:516 > > Little unsure where gawk stops and musl begins. I guess #6 is where it > goes wrong. Any musl developer want to work with me to figure this out? You are correct that #6 is where it starts, above that it's just the SIGSEGV signal handler. Do you think you can share your script and input? That would help anyone trying to reproduce the bug if they can't find the issue in the code via inspection. > > Ivo Palli > > ________________________________ > From: Rich Felker <dalias@libc.org> > Sent: Friday, September 24, 2021 14:37 > To: Ivo Palli <Ivo.Palli@bytesnet.nl> > Cc: musl@lists.openwall.com <musl@lists.openwall.com> > Subject: Re: [musl] Musl compiled gawk coredumps. How to find out where? > > On Fri, Sep 24, 2021 at 10:41:24AM +0000, Ivo Palli wrote: > > Hi there, > > > > I compiled gawk-4.2.1 (with gmp-6.2.1 and mpfr-4.1.0) using musl-1.2.2. > > > > Using it with I script I wrote I get > > > > gawk: /.../.../build_total.awk:25: (FILENAME=big.report FNR=6) fatal error: internal error > > ../go: line 36: 14488 Aborted (core dumped) > > > > Loading it into gdb doesn't give much information: > > > > # gdb -q ./gawk core.gawk.0.51bcaa32ed144d2498e3a70ff28af961.14488.1632479605000000 > > Reading symbols from ./gawk...done. > > [New LWP 14488] > > Core was generated by `gawk -i functions.awk -v TEMPLATE=... > > Program terminated with signal SIGABRT, Aborted. > > #0 0x00000000004cf169 in __restore_sigs () > > (gdb) backtrace > > #0 0x00000000004cf169 in __restore_sigs () > > #1 0x00000000004cf1c4 in raise () > > #2 0x0000000000000000 in ?? () > > (gdb) frame 0 > > #0 0x00000000004cf169 in __restore_sigs () > > (gdb) print > > The history is empty. > > (gdb) > > > > I compiled gawk the same with regular gcc (version 8.3.1 20190507 (Red Hat 8.3.1-4)) into a dynamic binary with the same libraries, and that did complete my script without crashing. > > > > Can anybody inform me how to find out exactly where the crash occurs and how I can help fix this bug? > > Try with musl and gawk built with debug info. If you're running with > musl provided by your distro, it probably has a debug symbols package > you can install. If you're building musl yourself, add --enable-debug > to configure command line or -g to CFLAGS manually. > > Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] Musl compiled gawk coredumps. How to find out where? 2021-09-24 13:48 [musl] Musl compiled gawk coredumps. How to find out where? Érico Nogueira @ 2021-09-24 14:38 ` Ivo Palli 2021-09-24 14:53 ` Ivo Palli 0 siblings, 1 reply; 8+ messages in thread From: Ivo Palli @ 2021-09-24 14:38 UTC (permalink / raw) To: musl, Rich Felker [-- Attachment #1: Type: text/plain, Size: 240 bytes --] >Do you think you can share your script and input? That would help anyone >trying to reproduce the bug if they can't find the issue in the code via >inspection. I'm afraid not. But I will put some effort into helping to find the bug. [-- Attachment #2: Type: text/html, Size: 1001 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] Musl compiled gawk coredumps. How to find out where? 2021-09-24 14:38 ` Ivo Palli @ 2021-09-24 14:53 ` Ivo Palli 2021-09-24 15:39 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Ivo Palli @ 2021-09-24 14:53 UTC (permalink / raw) To: musl, Rich Felker [-- Attachment #1: Type: text/plain, Size: 5729 bytes --] Ok, I've got some valgrind output: Program terminated with signal SIGABRT, Aborted. #0 __restore_sigs (set=set@entry=0x1ffeffe910) at ./arch/x86_64/syscall_arch.h:40 40 return ret; (gdb) backtrace #0 __restore_sigs (set=set@entry=0x1ffeffe910) at ./arch/x86_64/syscall_arch.h:40 #1 0x00000000004cf1c4 in raise (sig=sig@entry=6) at src/signal/raise.c:11 #2 0x00000000004c96ea in abort () at src/exit/abort.c:11 #3 0x0000000000452f16 in catchsig (sig=<optimized out>) at main.c:1231 #4 catchsig (sig=<optimized out>) at main.c:1217 #5 <signal handler called> #6 get_meta (p=p@entry=0x4a5af50 "\260\232\243\001") at src/malloc/mallocng/meta.h:141 #7 0x00000000004ca62c in __libc_free (p=0x4a5af50) at src/malloc/mallocng/free.c:105 #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x48728c8) at node.c:492 #9 0x00000000004456e5 in unref (r=0x48728c8) at awk.h:1898 #10 purge_record () at field.c:360 #11 0x0000000000445f36 in set_record ( buf=0x549bdae "SIZE\t1KB\t192758\t112698119\nSIZE\t4KB\t462090\t1122421206\nSIZE\t16KB\t355596\t3138948391\nSIZE\t64KB\t413028\t13558910172\nSIZE\t256KB\t1014012\t165385758947\nSIZE\t1MB\t2546508\t1346405498466\nSIZE\t10MB\t480844\t1602796961"..., cnt=25, fw=0x0) at field.c:269 #12 0x000000000044e765 in inrec (iop=<optimized out>, errcode=errcode@entry=0x1ffefffa50) at io.c:608 #13 0x00000000004414f8 in h_interpret (code=<optimized out>) at interpret.h:1289 #14 0x0000000000402631 in main (argc=<optimized out>, argv=<optimized out>) at main.c:516 (gdb) frame 8 #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x48728c8) at node.c:492 492 mpfr_unset(tmp); (gdb) print tmp $1 = (NODE *) 0x48728c8 (gdb) print *tmp $2 = {sub = {nodep = {l = {lptr = 0x100000002, li = 0x100000002, ll = 4294967298, lp = 0x100000002}, r = {rptr = 0x4a5af50, preg = {0x4a5af50, 0x0}, av = 0x4a5af50, bv = 0x4a5af50, uptr = 0x4a5af50, iptr = 0x4a5af50}, x = {extra = 0x0, aptr = 0x0, xl = 0}, name = 0x4e <error: Cannot access memory at address 0x4e>, reserved = 75884000, rn = 0x8, cnt = 0, reflags = 4294967295}, val = {nm = {fltnum = 2.1219957919534036e-314, mpnum = {{_mpfr_prec = 4294967298, _mpfr_sign = 77967184, _mpfr_exp = 0, _mpfr_d = 0x0}}, mpi = {{ _mp_alloc = 2, _mp_size = 1, _mp_d = 0x4a5af50}}}, rndmode = 78, sp = 0x485e5e0 "27499184", slen = 8, sref = 0, idx = -1, wsp = 0x0, wslen = 0, typre = 0x0}}, type = Node_val, flags = 2108} ==43165== Conditional jump or move depends on uninitialised value(s) ==43165== at 0x4CA82E: enframe (meta.h:204) ==43165== by 0x462EAB: xrealloc (xalloc.h:173) ==43165== by 0x462EAB: xpalloc (dfa.c:850) ==43165== by 0x462F52: copy.isra.10 (dfa.c:2043) ==43165== by 0x464BC1: dfaanalyze (dfa.c:2490) ==43165== by 0x4679F2: dfacomp (dfa.c:3527) ==43165== by 0x45F596: make_regexp (re.c:230) ==43165== by 0x413740: make_regnode (awkgram.y:5026) ==43165== by 0x416C08: yyparse (awkgram.y:505) ==43165== by 0x41B443: parse_program (awkgram.y:2587) ==43165== by 0x4025AB: main (main.c:469) ==43165== Uninitialised value was created by a stack allocation ==43165== at 0x4760E3: re_compile_internal (regcomp.c:755) ==43165== ==43165== Conditional jump or move depends on uninitialised value(s) ==43165== at 0x4CA82E: enframe (meta.h:204) ==43165== by 0x4D837D: __libc_realloc (realloc.c:46) ==43165== by 0x46B977: test_realloc (regex_internal.h:476) ==43165== by 0x46B977: re_dfa_add_node (regex_internal.c:1438) ==43165== by 0x46BA7A: duplicate_node (regcomp.c:1643) ==43165== by 0x46BC59: duplicate_node_closure (regcomp.c:1566) ==43165== by 0x46E3CF: calc_eclosure_iter.isra.30 (regcomp.c:1745) ==43165== by 0x47660C: calc_eclosure (regcomp.c:1708) ==43165== by 0x47660C: analyze (regcomp.c:1235) ==43165== by 0x47660C: re_compile_internal (regcomp.c:821) ==43165== by 0x476EB9: re_compile_pattern (regcomp.c:256) ==43165== by 0x45F0FA: make_regexp (re.c:215) ==43165== by 0x413765: make_regnode (awkgram.y:5031) ==43165== by 0x416C08: yyparse (awkgram.y:505) ==43165== by 0x41B443: parse_program (awkgram.y:2587) ==43165== Uninitialised value was created by a stack allocation ==43165== at 0x4760E3: re_compile_internal (regcomp.c:755) ==43165== ==43165== Conditional jump or move depends on uninitialised value(s) ==43165== at 0x4CA82E: enframe (meta.h:204) ==43165== by 0x462D44: xmalloc (xalloc.h:147) ==43165== by 0x46770C: xnmalloc (xalloc.h:134) ==43165== by 0x46770C: dfassbuild (dfa.c:3455) ==43165== by 0x46770C: dfacomp (dfa.c:3522) ==43165== by 0x45F596: make_regexp (re.c:230) ==43165== by 0x413765: make_regnode (awkgram.y:5031) ==43165== by 0x416C08: yyparse (awkgram.y:505) ==43165== by 0x41B443: parse_program (awkgram.y:2587) ==43165== by 0x4025AB: main (main.c:469) ==43165== Uninitialised value was created by a stack allocation ==43165== at 0x4760E3: re_compile_internal (regcomp.c:755) ==43165== Since it looks like a gawk bug, not directly anything to do with musl, I'll see if I can submit a bug report with the gawk maintainers. Ivo Palli ________________________________ From: Ivo Palli <Ivo.Palli@bytesnet.nl> Sent: Friday, September 24, 2021 16:38 To: musl@lists.openwall.com <musl@lists.openwall.com>; Rich Felker <dalias@libc.org> Subject: Re: [musl] Musl compiled gawk coredumps. How to find out where? >Do you think you can share your script and input? That would help anyone >trying to reproduce the bug if they can't find the issue in the code via >inspection. I'm afraid not. But I will put some effort into helping to find the bug. [-- Attachment #2: Type: text/html, Size: 10037 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] Musl compiled gawk coredumps. How to find out where? 2021-09-24 14:53 ` Ivo Palli @ 2021-09-24 15:39 ` Rich Felker 0 siblings, 0 replies; 8+ messages in thread From: Rich Felker @ 2021-09-24 15:39 UTC (permalink / raw) To: Ivo Palli; +Cc: musl On Fri, Sep 24, 2021 at 02:53:39PM +0000, Ivo Palli wrote: > Ok, I've got some valgrind output: > > Program terminated with signal SIGABRT, Aborted. > #0 __restore_sigs (set=set@entry=0x1ffeffe910) at ./arch/x86_64/syscall_arch.h:40 > 40 return ret; > (gdb) backtrace > #0 __restore_sigs (set=set@entry=0x1ffeffe910) at ./arch/x86_64/syscall_arch.h:40 > #1 0x00000000004cf1c4 in raise (sig=sig@entry=6) at src/signal/raise.c:11 > #2 0x00000000004c96ea in abort () at src/exit/abort.c:11 > #3 0x0000000000452f16 in catchsig (sig=<optimized out>) at main.c:1231 > #4 catchsig (sig=<optimized out>) at main.c:1217 > #5 <signal handler called> > #6 get_meta (p=p@entry=0x4a5af50 "\260\232\243\001") at src/malloc/mallocng/meta.h:141 > #7 0x00000000004ca62c in __libc_free (p=0x4a5af50) at src/malloc/mallocng/free.c:105 > #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x48728c8) at node.c:492 > #9 0x00000000004456e5 in unref (r=0x48728c8) at awk.h:1898 > #10 purge_record () at field.c:360 > #11 0x0000000000445f36 in set_record ( > buf=0x549bdae "SIZE\t1KB\t192758\t112698119\nSIZE\t4KB\t462090\t1122421206\nSIZE\t16KB\t355596\t3138948391\nSIZE\t64KB\t413028\t13558910172\nSIZE\t256KB\t1014012\t165385758947\nSIZE\t1MB\t2546508\t1346405498466\nSIZE\t10MB\t480844\t1602796961"..., cnt=25, fw=0x0) at field.c:269 > #12 0x000000000044e765 in inrec (iop=<optimized out>, errcode=errcode@entry=0x1ffefffa50) at io.c:608 > #13 0x00000000004414f8 in h_interpret (code=<optimized out>) at interpret..h:1289 > #14 0x0000000000402631 in main (argc=<optimized out>, argv=<optimized out>) at main.c:516 > (gdb) frame 8 > #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x48728c8) at node.c:492 > 492 mpfr_unset(tmp); > (gdb) print tmp > $1 = (NODE *) 0x48728c8 > (gdb) print *tmp > $2 = {sub = {nodep = {l = {lptr = 0x100000002, li = 0x100000002, ll = 4294967298, lp = 0x100000002}, r = {rptr = 0x4a5af50, preg = {0x4a5af50, 0x0}, av = 0x4a5af50, bv = 0x4a5af50, > uptr = 0x4a5af50, iptr = 0x4a5af50}, x = {extra = 0x0, aptr = 0x0, xl = 0}, name = 0x4e <error: Cannot access memory at address 0x4e>, reserved = 75884000, rn = 0x8, cnt = 0, > reflags = 4294967295}, val = {nm = {fltnum = 2.1219957919534036e-314, mpnum = {{_mpfr_prec = 4294967298, _mpfr_sign = 77967184, _mpfr_exp = 0, _mpfr_d = 0x0}}, mpi = {{ > _mp_alloc = 2, _mp_size = 1, _mp_d = 0x4a5af50}}}, rndmode = 78, sp = 0x485e5e0 "27499184", slen = 8, sref = 0, idx = -1, wsp = 0x0, wslen = 0, typre = 0x0}}, > type = Node_val, flags = 2108} > > > ==43165== Conditional jump or move depends on uninitialised value(s) > ==43165== at 0x4CA82E: enframe (meta.h:204) > ==43165== by 0x462EAB: xrealloc (xalloc.h:173) > ==43165== by 0x462EAB: xpalloc (dfa.c:850) > ==43165== by 0x462F52: copy.isra.10 (dfa.c:2043) > ==43165== by 0x464BC1: dfaanalyze (dfa.c:2490) > ==43165== by 0x4679F2: dfacomp (dfa.c:3527) > ==43165== by 0x45F596: make_regexp (re.c:230) > ==43165== by 0x413740: make_regnode (awkgram.y:5026) > ==43165== by 0x416C08: yyparse (awkgram.y:505) > ==43165== by 0x41B443: parse_program (awkgram.y:2587) > ==43165== by 0x4025AB: main (main.c:469) > ==43165== Uninitialised value was created by a stack allocation > ==43165== at 0x4760E3: re_compile_internal (regcomp.c:755) > ==43165== > ==43165== Conditional jump or move depends on uninitialised value(s) > ==43165== at 0x4CA82E: enframe (meta.h:204) > ==43165== by 0x4D837D: __libc_realloc (realloc.c:46) > ==43165== by 0x46B977: test_realloc (regex_internal.h:476) > ==43165== by 0x46B977: re_dfa_add_node (regex_internal.c:1438) > ==43165== by 0x46BA7A: duplicate_node (regcomp.c:1643) > ==43165== by 0x46BC59: duplicate_node_closure (regcomp.c:1566) > ==43165== by 0x46E3CF: calc_eclosure_iter.isra.30 (regcomp.c:1745) > ==43165== by 0x47660C: calc_eclosure (regcomp.c:1708) > ==43165== by 0x47660C: analyze (regcomp.c:1235) > ==43165== by 0x47660C: re_compile_internal (regcomp.c:821) > ==43165== by 0x476EB9: re_compile_pattern (regcomp.c:256) > ==43165== by 0x45F0FA: make_regexp (re.c:215) > ==43165== by 0x413765: make_regnode (awkgram.y:5031) > ==43165== by 0x416C08: yyparse (awkgram.y:505) > ==43165== by 0x41B443: parse_program (awkgram.y:2587) > ==43165== Uninitialised value was created by a stack allocation > ==43165== at 0x4760E3: re_compile_internal (regcomp.c:755) > ==43165== > ==43165== Conditional jump or move depends on uninitialised value(s) > ==43165== at 0x4CA82E: enframe (meta.h:204) > ==43165== by 0x462D44: xmalloc (xalloc.h:147) > ==43165== by 0x46770C: xnmalloc (xalloc.h:134) > ==43165== by 0x46770C: dfassbuild (dfa.c:3455) > ==43165== by 0x46770C: dfacomp (dfa.c:3522) > ==43165== by 0x45F596: make_regexp (re.c:230) > ==43165== by 0x413765: make_regnode (awkgram.y:5031) > ==43165== by 0x416C08: yyparse (awkgram.y:505) > ==43165== by 0x41B443: parse_program (awkgram.y:2587) > ==43165== by 0x4025AB: main (main.c:469) > ==43165== Uninitialised value was created by a stack allocation > ==43165== at 0x4760E3: re_compile_internal (regcomp.c:755) > ==43165== > > Since it looks like a gawk bug, not directly anything to do with > musl, I'll see if I can submit a bug report with the gawk > maintainers. Here valgrind is not succeeding in interposing its own malloc debugging, so you're not getting meaningful output. If you don't have an environment for running musl-linked programs under valgrind (easy if you have a musl-based distro, but if not it probably needs some patches for whatever valgrind is getting wrong), see what happens if you build the same version of gawk against glibc and run it under valgrind. I would expect the same error to be visible. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* [musl] Musl compiled gawk coredumps. How to find out where? @ 2021-09-24 10:41 Ivo Palli 2021-09-24 12:37 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Ivo Palli @ 2021-09-24 10:41 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1186 bytes --] Hi there, I compiled gawk-4.2.1 (with gmp-6.2.1 and mpfr-4.1.0) using musl-1.2.2. Using it with I script I wrote I get gawk: /.../.../build_total.awk:25: (FILENAME=big.report FNR=6) fatal error: internal error ./go: line 36: 14488 Aborted (core dumped) Loading it into gdb doesn't give much information: # gdb -q ./gawk core.gawk.0.51bcaa32ed144d2498e3a70ff28af961.14488.1632479605000000 Reading symbols from ./gawk...done. [New LWP 14488] Core was generated by `gawk -i functions.awk -v TEMPLATE=... Program terminated with signal SIGABRT, Aborted. #0 0x00000000004cf169 in __restore_sigs () (gdb) backtrace #0 0x00000000004cf169 in __restore_sigs () #1 0x00000000004cf1c4 in raise () #2 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004cf169 in __restore_sigs () (gdb) print The history is empty. (gdb) I compiled gawk the same with regular gcc (version 8.3.1 20190507 (Red Hat 8.3.1-4)) into a dynamic binary with the same libraries, and that did complete my script without crashing. Can anybody inform me how to find out exactly where the crash occurs and how I can help fix this bug? Regards, Ivo Palli [-- Attachment #2: Type: text/html, Size: 3200 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] Musl compiled gawk coredumps. How to find out where? 2021-09-24 10:41 Ivo Palli @ 2021-09-24 12:37 ` Rich Felker 2021-09-24 13:02 ` Ivo Palli 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2021-09-24 12:37 UTC (permalink / raw) To: Ivo Palli; +Cc: musl On Fri, Sep 24, 2021 at 10:41:24AM +0000, Ivo Palli wrote: > Hi there, > > I compiled gawk-4.2.1 (with gmp-6.2.1 and mpfr-4.1.0) using musl-1.2.2. > > Using it with I script I wrote I get > > gawk: /.../.../build_total.awk:25: (FILENAME=big.report FNR=6) fatal error: internal error > ../go: line 36: 14488 Aborted (core dumped) > > Loading it into gdb doesn't give much information: > > # gdb -q ./gawk core.gawk.0.51bcaa32ed144d2498e3a70ff28af961.14488.1632479605000000 > Reading symbols from ./gawk...done. > [New LWP 14488] > Core was generated by `gawk -i functions.awk -v TEMPLATE=... > Program terminated with signal SIGABRT, Aborted. > #0 0x00000000004cf169 in __restore_sigs () > (gdb) backtrace > #0 0x00000000004cf169 in __restore_sigs () > #1 0x00000000004cf1c4 in raise () > #2 0x0000000000000000 in ?? () > (gdb) frame 0 > #0 0x00000000004cf169 in __restore_sigs () > (gdb) print > The history is empty. > (gdb) > > I compiled gawk the same with regular gcc (version 8.3.1 20190507 (Red Hat 8.3.1-4)) into a dynamic binary with the same libraries, and that did complete my script without crashing. > > Can anybody inform me how to find out exactly where the crash occurs and how I can help fix this bug? Try with musl and gawk built with debug info. If you're running with musl provided by your distro, it probably has a debug symbols package you can install. If you're building musl yourself, add --enable-debug to configure command line or -g to CFLAGS manually. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] Musl compiled gawk coredumps. How to find out where? 2021-09-24 12:37 ` Rich Felker @ 2021-09-24 13:02 ` Ivo Palli 2021-09-24 13:48 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Ivo Palli @ 2021-09-24 13:02 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- Attachment #1: Type: text/plain, Size: 3372 bytes --] That helped! (gdb) backtrace #0 __restore_sigs (set=set@entry=0x7fff62ee5de0) at ./arch/x86_64/syscall_arch.h:40 #1 0x00000000004cf1c4 in raise (sig=sig@entry=6) at src/signal/raise.c:11 #2 0x00000000004c96ea in abort () at src/exit/abort.c:11 #3 0x0000000000452f16 in catchsig (sig=<optimized out>) at main.c:1231 #4 catchsig (sig=<optimized out>) at main.c:1217 #5 <signal handler called> #6 get_meta (p=p@entry=0x7f4d35d74f50 "\260\232\243\001") at src/malloc/mallocng/meta.h:141 #7 0x00000000004ca62c in __libc_free (p=0x7f4d35d74f50) at src/malloc/mallocng/free.c:105 #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x7f4d35f5c778) at node.c:492 #9 0x00000000004456e5 in unref (r=0x7f4d35f5c778) at awk.h:1898 #10 purge_record () at field.c:360 #11 0x0000000000445f36 in set_record ( buf=0x7f4d34f34cfe "SIZE\t1KB\t192758\t112698119\nSIZE\t4KB\t462090\t1122421206\nSIZE\t16KB\t355596\t3138948391\nSIZE\t64KB\t413028\t13558910172\nSIZE\t256KB\t1014012\t165385758947\nSIZE\t1MB\t2546508\t1346405498466\nSIZE\t10MB\t480844\t1602796961"..., cnt=25, fw=0x0) at field.c:269 #12 0x000000000044e765 in inrec (iop=<optimized out>, errcode=errcode@entry=0x7fff62ee6cb0) at io.c:608 #13 0x00000000004414f8 in h_interpret (code=<optimized out>) at interpret.h:1289 #14 0x0000000000402631 in main (argc=<optimized out>, argv=<optimized out>) at main.c:516 Little unsure where gawk stops and musl begins. I guess #6 is where it goes wrong. Any musl developer want to work with me to figure this out? Ivo Palli ________________________________ From: Rich Felker <dalias@libc.org> Sent: Friday, September 24, 2021 14:37 To: Ivo Palli <Ivo.Palli@bytesnet.nl> Cc: musl@lists.openwall.com <musl@lists.openwall.com> Subject: Re: [musl] Musl compiled gawk coredumps. How to find out where? On Fri, Sep 24, 2021 at 10:41:24AM +0000, Ivo Palli wrote: > Hi there, > > I compiled gawk-4.2.1 (with gmp-6.2.1 and mpfr-4.1.0) using musl-1.2.2. > > Using it with I script I wrote I get > > gawk: /.../.../build_total.awk:25: (FILENAME=big.report FNR=6) fatal error: internal error > ../go: line 36: 14488 Aborted (core dumped) > > Loading it into gdb doesn't give much information: > > # gdb -q ./gawk core.gawk.0.51bcaa32ed144d2498e3a70ff28af961.14488.1632479605000000 > Reading symbols from ./gawk...done. > [New LWP 14488] > Core was generated by `gawk -i functions.awk -v TEMPLATE=... > Program terminated with signal SIGABRT, Aborted. > #0 0x00000000004cf169 in __restore_sigs () > (gdb) backtrace > #0 0x00000000004cf169 in __restore_sigs () > #1 0x00000000004cf1c4 in raise () > #2 0x0000000000000000 in ?? () > (gdb) frame 0 > #0 0x00000000004cf169 in __restore_sigs () > (gdb) print > The history is empty. > (gdb) > > I compiled gawk the same with regular gcc (version 8.3.1 20190507 (Red Hat 8.3.1-4)) into a dynamic binary with the same libraries, and that did complete my script without crashing. > > Can anybody inform me how to find out exactly where the crash occurs and how I can help fix this bug? Try with musl and gawk built with debug info. If you're running with musl provided by your distro, it probably has a debug symbols package you can install. If you're building musl yourself, add --enable-debug to configure command line or -g to CFLAGS manually. Rich [-- Attachment #2: Type: text/html, Size: 5562 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [musl] Musl compiled gawk coredumps. How to find out where? 2021-09-24 13:02 ` Ivo Palli @ 2021-09-24 13:48 ` Rich Felker 0 siblings, 0 replies; 8+ messages in thread From: Rich Felker @ 2021-09-24 13:48 UTC (permalink / raw) To: Ivo Palli; +Cc: musl On Fri, Sep 24, 2021 at 01:02:27PM +0000, Ivo Palli wrote: > That helped! > > (gdb) backtrace > #0 __restore_sigs (set=set@entry=0x7fff62ee5de0) at ./arch/x86_64/syscall_arch.h:40 > #1 0x00000000004cf1c4 in raise (sig=sig@entry=6) at src/signal/raise.c:11 > #2 0x00000000004c96ea in abort () at src/exit/abort.c:11 > #3 0x0000000000452f16 in catchsig (sig=<optimized out>) at main.c:1231 > #4 catchsig (sig=<optimized out>) at main.c:1217 > #5 <signal handler called> > #6 get_meta (p=p@entry=0x7f4d35d74f50 "\260\232\243\001") at src/malloc/mallocng/meta.h:141 > #7 0x00000000004ca62c in __libc_free (p=0x7f4d35d74f50) at src/malloc/mallocng/free.c:105 > #8 0x0000000000459d57 in r_unref (tmp=tmp@entry=0x7f4d35f5c778) at node.c:492 > #9 0x00000000004456e5 in unref (r=0x7f4d35f5c778) at awk.h:1898 > #10 purge_record () at field.c:360 > #11 0x0000000000445f36 in set_record ( > buf=0x7f4d34f34cfe "SIZE\t1KB\t192758\t112698119\nSIZE\t4KB\t462090\t1122421206\nSIZE\t16KB\t355596\t3138948391\nSIZE\t64KB\t413028\t13558910172\nSIZE\t256KB\t1014012\t165385758947\nSIZE\t1MB\t2546508\t1346405498466\nSIZE\t10MB\t480844\t1602796961"..., cnt=25, fw=0x0) at field.c:269 > #12 0x000000000044e765 in inrec (iop=<optimized out>, errcode=errcode@entry=0x7fff62ee6cb0) at io.c:608 > #13 0x00000000004414f8 in h_interpret (code=<optimized out>) at interpret..h:1289 > #14 0x0000000000402631 in main (argc=<optimized out>, argv=<optimized out>) at main.c:516 > > Little unsure where gawk stops and musl begins. I guess #6 is where > it goes wrong. Any musl developer want to work with me to figure > this out? Line 141 of meta.h is catching double-free. This is almost surely a bug in gawk, potentially a serious one. Running under valgrind might tell you more about where the corresponding alloc and previous free occurred. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-24 15:39 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-24 13:48 [musl] Musl compiled gawk coredumps. How to find out where? Érico Nogueira 2021-09-24 14:38 ` Ivo Palli 2021-09-24 14:53 ` Ivo Palli 2021-09-24 15:39 ` Rich Felker -- strict thread matches above, loose matches on Subject: below -- 2021-09-24 10:41 Ivo Palli 2021-09-24 12:37 ` Rich Felker 2021-09-24 13:02 ` Ivo Palli 2021-09-24 13:48 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).