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
