Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

[Ximin Luo]

Edmund Grimley Evans:
>> http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?p=8963#p8963
>>
>> Do you have any suggestions on how to move forward? The easiest option is just to give the test two possible things to diff against, but this buries the issue and does not really solve it.
> 
> That looks worrying. It might be a real bug.
> 
> If I've understood correctly, you get different behaviour with and
> without the patch on amd64. But the patch consists of a load of
> independent changes. So, if we can't think of anything else, there's
> the option here of doing a bisection search to find out which hunk of
> the patch causes the difference. (Though it could be more complicated
> I suppose: like whether an odd or even number of hunks are applied...)
> 

Not amd64 but arm64 - the Debian name for aarch64 / armv8. But yes to the other parts of what you said. Alright, thanks for the tips, I'll try the bisect when I get some time.

Actually there was a paper posted to Hacker News yesterday: https://www.st.cs.uni-saarland.de/publications/files/zeller-esec-1999.pdf whose algorithm would be perfect for this sort of thing, unfortunately I don't think it was released as a piece of executable software :(

> Is -1 cast to a pointer being used as a special value somewhere? That
> value would not survive being packed and unpacked.
> 
>> Another thing now: your robopatch results in the following patch:
>>
>> https://anonscm.debian.org/cgit/debian-science/packages/giac.git/tree/debian/patches/fix-48-bit-addr.patch?id=075cd498f2590ed067e73da827a5cb07b4d1aa5b
>>
>> As you can see, it makes some changes to src/cocoa.cc that are not guarded by #ifdef SMARTPTR64 conditions. Judging by your perl expression, I guess this should also be unpatched?
> 
> I think that code in cocoa.cc is wrong either way: (1<<31) is an
> overflow already, whatever you cast it to afterwards. It should
> probably be (1LL<31), and then there's no need to convert it to
> longlong or ulonglong, i.e.: gen p(int((1LL<<31)-1))
> 

I see right, according to the C/C++ standards you shouldn't perform operations that require more than 16 bits on these. But I think the existing results that we're getting probably wouldn't be affected since they are running on machines where ints do have >= 32 bits so it wouldn't be overflowing in practice in these cases.

>> Similarly, src/ifactor.cc and the third hunk of src/vecteur.cc should probably be reverted just for "neatness" purposes, but I don't think this would have affected any of the results described.
> 
> src/ifactor.cc looks like a false positive: the << is not a shift. So
> revert that.
> 
> Third hunk of vecteur.cc should make no difference either way.
> 
> So I'd recommend trying to discover which part of that patch changes
> the test result on amd64, and maybe it will then be possible to
> understand why...
> 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git