[Info-vax] Problems with multithreaded calls to libCURL

[Craig A. Berry]

On 3/7/19 6:08 PM, Jim Duff wrote:
> On 8/3/19 10:31 am, Craig A. Berry wrote:
>>
>> On 3/7/19 5:09 PM, Jim Duff wrote:
>>> Versions:
>>>
>>> OpenVMS 8.4 on IA64
>>> HP C V7.2-001:
>>> libCURL: 7.4.7
>>
>> Is that supposed to be 7.47.0?  I haven't looked for upgrades in a long
>> time and I have:
>>
>> $ curl --version
>> curl 7.43.0 (IA64-HP-VMS) libcurl/7.43.0 OpenSSL/0.9.8ze zlib/1.2.8
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>> pop3 pop3s rtsp smtp smtps telnet tftp
>> Features: IPv6 Largefile GSS-API Kerberos SPNEGO NTLM SSL libz
>>
> 
> Yes, sorry, 7.47.0
> 
>>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
>>> address=000000000000
>>> 0028, PC=FFFFFFFF84088EB0, PS=0000001B
>>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>>> image     module    routine               line      rel PC
>>> abs PC
>>
>> [snip]
>>
>>> DECC$SHR  C$SETJMP  sigsetjmp            17136 00000000000008B2
>>> FFFFFFFF84B6DBE2
>>
>> [snip]
>>
>> Threads are tricky.  Threads with signals, especially on VMS, where all
>> signal delivery happens in the main thread, are kinda scary.  Have a
>> look at
>>
>> $ help crtl sigsetjmp restrictions
>>
> 
> If my code was using sigsetjmp (), I'd be right with you, but it's not.
>   And a search of the CURL C modules does not turn up any matches either,
> so I'm not sure if it's related or a result of the accvio traceback...

Your code may not be calling it, but libcurl definitely is, as the stack
trace you posted makes clear. See:

<https://github.com/curl/curl/blob/aa1f1d48f3e86fc20c38da635b54ec060d68cb45/lib/hostip.c#L706>