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:[email protected]?subject=Unsubscribe
