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

[Ximin Luo]

On Thu, 29 Jun 2017 20:40:26 +0100 Edmund Grimley Evans <edmund.grimley.evans at gmail.com> wrote:
> This robopatch seems to fix the problem on arm64 with 48-bit addresses:
> 
> perl -i -pe 's/longlong/ulonglong/g if /\(\s*longlong.*(<<|>>)/ &&
> !/gen\(longlong/;' src/*.cc
> 
> The idea is to change the type whenever there seems to be a cast
> followed by a shift. The last condition is to avoid a couple of
> harmful false positives.
> 
> [..]

Hey Edmund, thanks for all your help with this!

I've tested your robopatch and it works. However, now I'm experiencing this issue:

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.

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 tried this, things still work, unfortunately chk_fhan16 still fails. But from what I understand of your explanation, it would be best to leave this part out of the patch. Is that right?

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.

X

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