On 16/01/2017 20:26, Jon Turney wrote:
> On 16/01/2017 20:07, Sam Edge wrote:
>> On 09/01/2017 19:07, Sam Edge wrote:
>>> On 09/01/2017 02:04, Eliot Moss wrote:
>>>> On 1/8/2017 3:45 PM, David Rothenberger wrote:
>>>>> On 1/8/2017 6:12 AM, Sam Edge wrote:
>>>>>> I've seen a number of 'svn segfault' threads on the mailing list
>>>>>> archive
>>>>>> but none of them seem to cover this specific failure mode.
>>>>>> (Apologies if
>>>>>> one of them does!)
>>>>>>
>>>>>> I'm getting segfaults from svn but only when using ssh as the
>>>>>> schema.
>>>>>> The following three commands are all accessing the same server, the
>>>>>> name
>>>>>> of which has been changed to protect the guilty.
>>>>>>
>>>>>> --------
>>>>>> SamEdge@thor ~
>>>>>> $ ssh cmserver.XXXXXX.com
>>>>>> ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
>>>>>> commit-revprops depth log-revprops atomic-revprops partial-replay
>>>>>> inherited-props ephemeral-txnprops file-revs-reverse ) ) )
>>>>>> SamEdge@thor ~
>>>>>> $ svn ls svn+ssh://cmserver.XXXXXX.com/edl/
>>>>>> Segmentation fault (core dumped)
>>>> Assuming this is repeatable behavior, perhaps getting a trace using
>>>> strace would reveal some more useful information.
>>>>
>>>> Regards - Eliot Moss
>>>>
>>> Good idea.
>>>
>>> Strangely, on another Windows 7 64-bit machine svn+ssh to the same
>>> server is working fine for me. The most significant differences are
>>> that
>>> the 'working' machine is running Windows 7 Pro on an Intel CPU with
>>> Sophos AV and domain accounts whereas the 'failing' machine is
>>> Windows 7
>>> Home Premium on an AMD with MS Security Essentials and local accounts.
>>> These differences may or may not be relevant of course.
>>>
>>> Anyway, attached are the two strace outputs. Diffing them suggests that
>>> it's segfaulting in the fork() "system" call.
>
> Not quite, this strace has...
>
>> --- Process 5436 loaded C:\cygwin64\lib\sasl2_3\cygcrammd5-3.dll at
>> 00000003EA090000
>> --- Process 5436, exception c0000005 at 00000003EA023780
>> --- Process 5436 unloaded DLL at 00000003EA090000
>>   333   52465 [main] svn 5436 seterrno_from_win_error:
>> /home/corinna/src/cygwin/cygwin-2.6.1/cygwin-2.6.1-1.x86_64/src/newlib-cygwin/winsup/cygwin/dlfcn.cc:304
>> windows error 998
>>    24   52489 [main] svn 5436 geterrno_from_win_error: windows error
>> 998 == errno 14
>>    20   52509 [main] svn 5436 dlopen: ret 0x0
>
> and then a bit later
>
>>    21   91851 [main] svn 5436 fork: entering
>>   168   92019 [main] svn 5436 sig_send: sendsig 0x80, pid 5436,
>> signal -72, its_me 1
>>    19   92038 [main] svn 5436 sig_send: wakeup 0x28C
>>    24   92062 [main] svn 5436 sig_send: Waiting for pack.wakeup 0x28C
>>    36   92098 [sig] svn 5436 wait_sig: signalling pack.wakeup 0x28C
>>    27   92125 [main] svn 5436 sig_send: returning 0x0 from sending
>> signal -72
>> --- Process 5436, exception c0000005 at 0000000180053D3F
>
> So it looks like perhaps cygcrammd5 is faulting during it's DllMain,
> and perhaps this leaves things in a state that dll_list::topsort can't
> handle...
>
>>> I don't have time in the week to run it in a debug session but I'll try
>>> to do so at the weekend given the advice I've been given here. I will
>>> also do a rebaseall after I've tracked down the
>>>
>>> Thanks for the feedback folks. Much appreciated.
>>>
>>> BR
>>
>> Hi again.
>>
>> I've downloaded the debug symbols for subversion & the Cygwin dll and
>> run the command in gdb. Output attached. Not really giving me any clues
>> so far.
>
> You also need the symbols for the DLL loaded at the faulting address.
>
> From previous information I'd guess that is cyrus-sasl-debuginfo.
>
> (you can check this using gdb's 'info shared' command)
>
>> I've also run 'rebaseall' on the off chance that it would help - it
>> didn't!
>>
>> Still open to suggestions if anyone has any "light bulb" notions. :-)
>
Hi Jon. Thanks for the swift reply.

I've installed the debug as you suggested but it doesn't shed much light
to me. The attached gdb output doesn't seem any more enlightening. I'm a
little (!) out of my depth I think.

-- 
Sam Edge