mailing list of musl libc
 help / color / mirror / Atom feed
* 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

* 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

* 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 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

* [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

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

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git