Hi Jason, I did not try to install and run it.
But I think it is by chance that "+" has an influence on the crash. There must be a "hard" reason. What I can see from the stack backtrace, it crashes in 'consTree', so it must be in one of the 'idx' calls. Can you debug this a little more? E.g. look at the output of (traceAll) and see *where* exactly it happens. BTW, I cannot see your mail in the mail archive. Not sure if anyone else except me got it. Probably because you mailed to me and put the list only into CC. I send this directly to the list. ☺/ A!ex On Tue, Aug 01, 2023 at 10:34:48PM +0100, Jason Vas Dias wrote: > > Good day - > > Why, without a final '+' argument, does the attached program coredump, > when with a final '+' argument (enabling debugging) , it does not ? > > This is with picolisp 23.07.28 on my Fedora 36 12-core x86_86 laptop > PC - my route printing / processing program: > > $ ./L_RT.l -pr + > 0.0.0.0/0 wlp59s0 192.168.43.1 > UP,GW 600 { dev:wlp59s0 gateway:192.168.43.1 > metric:600 prefsrc:192.168.43.70 protocol:dhcp scope:global > type:unicast } > 0.0.0.0/32 * 0.0.0.0 > UP,HO 0 { protocol:boot scope:global > type:blackhole } > ... > > $ ./L_RT.l -pr > 192.168.42.1/32 ppp0 0.0.0.0 > UP,HO 0 { dev:ppp0 metric:50 > prefsrc:192.168.42.10 protocol:kernel scope:link type:unicast } > ... > Segmentation Fault > <coredump> : > [jvd@jvdspc]:~/src/pil21/src [3292] 22:05:06 [#:980!:28555]{1} > $ gdb ../bin/picolisp /tmp/pil.1800629.core > GNU gdb (GDB) Fedora 12.1-2.fc36 ... > Reading symbols from ../bin/picolisp... > (No debugging symbols found in ../bin/picolisp) > [New LWP 1800629] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/bin/picolisp /usr/lib/picolisp/lib.l > /usr/bin/pil /home/jvd/bin/L_RT.l -pr'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0000000000444921 in consTree () > Missing separate debuginfos, use: dnf debuginfo-install > libffi-3.4.2-8.fc36.x86_64 ncurses-libs-6.2-9.20210508.fc36.x86_64 > readline-8.2-2.fc36.x86_64 > (gdb) where > #0 0x0000000000444921 in consTree () > #1 0x0000000000422428 in _for () > #2 0x00000000004212f7 in _prog () > #3 0x000000000042324d in _let () > #4 0x000000000042324d in _let () > #5 0x0000000000432469 in evExpr () > #6 0x000000000041fd02 in _eval () > #7 0x00000000004211d8 in _bool () > #8 0x0000000000421218 in _not () > #9 0x00000000004214ac in _if () > #10 0x00000000004212f7 in _prog () > #11 0x000000000042324d in _let () > #12 0x000000000043e505 in loop1 () > #13 0x0000000000422573 in _for () > #14 0x000000000042324d in _let () > #15 0x000000000042324d in _let () > #16 0x00000000004238c7 in _catch () > #17 0x0000000000434476 in repl () > #18 0x00000000004495b8 in main () > (gdb) > > quit > </coredump> > > This is from the route which has 2 identical idx tree 'keys': > 192.168.42.1/32 ppp0 0.0.0.0 > UP,HO 0 { dev:ppp0 metric:50 > prefsrc:192.168.42.10 protocol:kernel scope:link type:unicast } > 192.168.42.1/32 ppp0 0.0.0.0 > UP,HO 50 { } > > Why does this situation cause a coredump / inability to process 'ip > route' output without final '+' command line argument in effect ? > Very strange - if the debugger is enabled , it > should detect a problem and trap to it, no ? > > Any constructive ideas / suggested workarounds gratefully received . > > Note, it is not fixed by doing a '(load "@lib/debug.l") in the program . > > I'd like to be able to NOT have to specify '+' on the command line to > avoid a coredump, OR , since debugging is enabled (with Emacs terminal > settings in effect) , and I have a valid $EMACS_SERVER_FILE setting > and Emacs server running, to bring up an Emacs debug session on > occurrence of SIGSEGV / SIGBUS - is this going to be possible with > a new picolisp version sometime soon ? > > Best Regards, > Jason > > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe