Hallo. Cág wrote in <20180927225715.iv3ds%c...@bitmessage.ch>: |Steffen Nurpmeso wrote: |> I cannot reproduce it at a glance via AlpineLinux: |> [...] |> It seems i have to boot my NetBSD 8 VM, it could be that the fix |> takes until tomorrow, thus. (Very slow, dependent on how weird it |> is...) | |I forgot to mention that I use s-nail with torify, but the same seems
You happen to use tor via *socks-proxy*? That is pretty cool, i still have not tried to use tor at all, even though i am tracking the announcements and the source code (since "Import v0.3.0.7, 2017-05-26", but the heck!, just cannot find any time). I have tested *socks-proxy* only via ssh(1)... |to happen without it. Also it's not the same all the time: I reconnected |with `dhclient -r`, then the usual wpa_supplicant+dhclient thing, s-nail |just hanged after "G": Yeah, as i wrote in the other mail, set *verbose* to see the progress ticks. I will change that and activate them in interactive mode automatically. |-- |^C |Interrupting this operation may turn the DNS resolver unusable |^Cs-nail interrupted Uh!!! This is hard :). |Interrupt |There are new messages in the error [...] |[...] |ERROR# ? q |Held messages in [my inbox] |[1] Segmentation fault (core dumped) s-nail I am very sorry Cág, but until v15 this codebase uses siglongjmp(), and except for libjp(e???)g each and every library i know will occasionally just break after such a longjmp. There is nothing that can be done here, but it is all my fault, i should have set back in 2012 and refrain from working with the nail codebase as such, instead i should have taken the OpenBSD Mail and develop from there on, and all this signal mess would simply not exist. This is v15, with SysV signal handling. Until then the above can happen. This is actually stated in the manual sections CAVEATS. |Maybe make flags should be noted [shameless stolen from the APKBUILD]: |VAL_IDNA=idn |VAL_RANDOM="libgetrandom sysgetrandom urandom builtin" Hmm. Likely better to not use such things at all unless you want a fixed configuration; NetBSD has arc4random: . VAL_RANDOM: arc4random(3) ... yes but forcing usage of the system OpenSSL may be an option VAL_RANDOM=tls,arc4 Not to talk about the unscientific builtin arc4, but well, needless, needless... |There are patches also used, I am attaching them, though they don't seem |to be related to the issue, and they don't exist in aports. Should I |remove them? Yes! Yes!! Yes!!! How could you apply them to v14.9.11???? I would nonetheless be interested in the NYD, i think i will try and see what i can do to make this better on NetBSD. That we crash in non-network code after such an interruption, that is very very bad! |Thanks, Steffen! A nice weekend, Dohle! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
