Good day Alex - RE: >Can you debug this a little more? E.g. look at the output of (traceAll) and see > *where* exactly it happens.
That's the whole problem - doesn't 'traceAll' depend on Debug Mode being enabled by trailing '+' ? And the coredump does NOT occur in debug mode, nor in normal usage where there are not 2 routes that share the same Key / destination . The coredump only occurs when NOT in Debug Mode, only when 2 routes share the same IDX Key / destination . Best Regards, Jason On 02/08/2023, Alexander Burger <picolisp@software-lab.de> wrote: > 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