Am 26.01.2020 um 09:38 schrieb Marco Atzeri:
> Am 26.01.2020 um 09:05 schrieb ASSI:
>> Marco Atzeri writes:
>>> at least I know that is not just my machine.
>>> When I released the package was
>>>
>>>
>>>    libinterp/corefcn/file-io.cc-tst
>>> ............................... PASS 90/90
>>
>> Based on the test name there may be an assumption built into the code
>> about how the filesystem behaves that isn't guaranteed on Windows/Cygwin
>> or even POSIX.  If it's simply an error condition not getting checked it
>> should be reproducible under debugging, but you're mostly out of luck if
>> it's relying on a specific order or atomicity of certain operations, as
>> debugging will almost always serialize the execution to the point where
>> these types of errors do not manifest.
>>
>>
>> Regards,
>> Achim.
> 
> the other problem of debugging is that the backtrace is trash
> after the segfault and that of course Octave is a
> 400 Kg gorilla with all its dependencies..
> 
> I will try anyway
> 
> Thanks
> Marco
> 

one thing that I noticed is that the old binary I released and
the new one built are behaving differently.

So whatever is the problem that you and me are seeing and that
Takashi's system seems immune is causing a difference at
compilation time in the executable:

Old binary:

octave:2> run test-round6a.m
octave:3> run test-round6b.m

New binary:

octave:1> run test-round6a.m
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

octave:1>  run test-round6b.m
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

Can you and Takashi provide me your cygcheck.out so that I can look on 
possible difference that could influence the build behaviour.

Of course I have W10 Home and Takashi a W10 Pro an that is already
a difference.

Regards
Marco