I should alsohave made more clear that on my host
it the core dump occurs when trying to print out this
pair of routes, printed by the trailing '+' debugging enabled run :
192.168.42.1/32 ppp0 0.0.0.0 UP,HO
0 { prefsrc:192.168.42.10 protocol:kernel
scope:link type:unicast }
192.168.42.1/32 ppp0 0.0.0.0 UP,HO
50 { }
These are created by libreSwan for my VPN. WHY it creates
2 routes with identical 'keys' ('dst' fields) I do not know , but
this is definitely part of the problem -- the code has previously called
(idx 'tri, (list "192.168.42.1/32" (list $attrList1 ...)) T)
..(idx 'tri, (list "192.168.42.1/32" (list $attrList2 ...)) T)
(ie. it is asking 'idx' to store 2 nodes with same key and
different contents).
Is this allowed ? The documentation suggests so IMHO.
Then, if so, there does appear to be a problem with interaction
of 'idx' and the '+' debugging mode that results in this coredump
&| the coredump causing problem not being detected.
Best Regards,
Jason
On 02/08/2023, Jason Vas Dias <jason.vas.d...@gmail.com> wrote:
> Good day, Mike -
>
> Without any arguments, it does nothing .
> I did write in previous mails (I think):
> $ pil L_RT.l -pr # coredumps
> / $ pil L_RT.l -pr + # no coredump
>
> Sorry if I did not make that clear .
> L_RT.l is a half-finished part of an appilication specific Web-Based
> IP + VPN + Router + Firewall + DNS + DHCP + RADIUS / LDAP + SNMP
> Configurator I am writing for my company.
> Without any arguments, it assumes it is just being Sourced and does nothing
> -
> Arguments :
> '-pr' | '-PR' | 'prin_route' : load & process routes , with a function
> that
> expects a single 'route' LIST argument
> .
> I got as far as getting it to merge the 2 main command-line accessable
> kernel RT-NETLINK route info data sources: /proc/net/route and 'ip route
> show'
> -- before discovering this pil bug, as I believe this is.
>
> Certainly, a pil debugger, when configured in Emacs mode, with an Emacs
> Server
> running, SHOULD IMHO attempt to bring up a picolisp Debug session and
> a GDB Debug Session in Emacs buffers using 'emacsclient -e' .
> That is what I am now focusing on getting working.
>
> But secondly, the debugger is not detecting any problems, yet a coredump
> occurs WITHOUT debugging enabled, which suggests a problem with the
> implementation of the special handling for the trailing '+' last member of
> (argv) (though this is never shown in lists returned by (argv) ).
>
> I just thought I should report this anomalous / buggy coredump to the pil
> development team - it is one that has got me foxed & don't have time
> to investigate it in depth .
>
> Best Regards,
> Jason
>
>
> On 02/08/2023, tankf33...@disroot.org <tankf33...@disroot.org> wrote:
>> On 02-08-2023 03:03, Jason Vas Dias wrote:
>>> Here's an improved version of that program,
>>
>> ====
>> $ pil L_RT.l
>> :
>> $
>> ====
>>
>> I have got just a prompt.
>>
>> (mike)
>>
>
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
