Segfault in tango.math.Math.poly using gdc

Sorry, too little information there - the backtrace :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210648896 (LWP 5267)]
0x08111e6a in _D5tango4math4Math4polyFeAeZe ()
(gdb) bt
#0  0x08111e6a in _D5tango4math4Math4polyFeAeZe ()
#1  0x08111ee3 in _D5tango4math4Math12rationalPolyFeAeAeZe ()
#2  0x080fbe6d in _D5tango4math6Bessel12cylBessel_j0FeZe ()
#3  0x080fc4cd in _D5tango4math6Bessel11__unittest0FZv ()
#4  0x080fdc3d in _D5tango4math6Bessel9__modtestFZv ()
#5  0x08180925 in _moduleUnitTests () at genobj.d:1161
#6  0x0817f7b3 in run () at dgccmain2.d:144
#7  0x0817f8d9 in _d_run_main (argc=1, argv=0xbfec3db4, main_func=0x80bcc84 <_Dmain>)
    at dgccmain2.d:155
#8  0x0817f65b in main (argc=0, argv=0x0) at cmain.d:5

This is thus in the math.Bessel unittest.

Happens in this test too

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209862464 (LWP 6159)]
0x0811171e in _D5tango4math4Math4polyFeAeZe ()
(gdb) bt
#0  0x0811171e in _D5tango4math4Math4polyFeAeZe ()
#1  0x081118ce in _D5tango4math4Math12rationalPolyFeAeAeZe ()
#2  0x080fc5bc in _D5tango4math6Bessel12cylBessel_j1FeZe ()
#3  0x080fceb8 in _D5tango4math6Bessel12cylBessel_jnFieZe ()
#4  0x080fd25a in _D5tango4math6Bessel11__unittest1FZv13testWronksianMFieZv ()
#5  0x080fd1a1 in _D5tango4math6Bessel11__unittest1FZv ()
#6  0x08180305 in _moduleUnitTests () at genobj.d:1161
#7  0x0817f193 in run () at dgccmain2.d:144
#8  0x0817f2b9 in _d_run_main (argc=1, argv=0xbfdefce4, main_func=0x80bcb14 <_Dmain>)
    at dgccmain2.d:155
#9  0x0817f03b in main (argc=0, argv=0x0) at cmain.d:5

ErrorFunction?

#0  0x081112c2 in _D5tango4math4Math4polyFeAeZe ()
#1  0x08111472 in _D5tango4math4Math12rationalPolyFeAeAeZe ()
#2  0x080fd4ec in _D5tango4math13ErrorFunction3erfFeZe ()
#3  0x080fd16e in _D5tango4math13ErrorFunction4erfcFeZe ()
#4  0x080fd524 in _D5tango4math13ErrorFunction11__unittest0FZv ()
#5  0x080fe76c in _D5tango4math13ErrorFunction9__modtestFZv ()
#6  0x0817feb5 in _moduleUnitTests () at genobj.d:1161
#7  0x0817ed43 in run () at dgccmain2.d:144
#8  0x0817ee69 in _d_run_main (argc=1, argv=0xbfd9a484, main_func=0x80bcad4 <_Dmain>)
    at dgccmain2.d:155

GammaFunction?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210378560 (LWP 8641)]
0x081102a2 in _D5tango4math4Math4polyFeAeZe ()
(gdb) bt
#0  0x081102a2 in _D5tango4math4Math4polyFeAeZe ()
#1  0x080fe074 in _D5tango4math13GammaFunction5gammaFeZe ()
#2  0x080fe599 in _D5tango4math13GammaFunction11__unittest1FZv ()
#3  0x081049a8 in _D5tango4math13GammaFunction9__modtestFZv ()
#4  0x0817ee95 in _moduleUnitTests () at genobj.d:1161
#5  0x0817dd23 in run () at dgccmain2.d:144
#6  0x0817de49 in _d_run_main (argc=1, argv=0xbff9c694, main_func=0x80bc754 <_Dmain>)
    at dgccmain2.d:155
#7  0x0817dbcb in main (argc=0, argv=0x0) at cmain.d:5

I just commented out everything in this file to proceed beyond this, so there may be more failures.

It also segfaulted in the unittest in math.Math mentioned on the top, and from math.Probability.

The problem could be in the Linux asm poly() code, which was copied straight from Phobos.

Please change tango.math.Math line 1594 (in poly) from

version (D_InlineAsm_X86)

to

version (D_InlineAsm_X86XX)

so that it doesn't use the asm version of poly. Does it still segfault if you do that?

No, the segfault goes away with that. I guess it's the calling convention difference between the compilers that is the problem?

Excellent! That narrows it down a lot.If it failed on both DMD Linux and GDC, I'd say it was an error in the poly code. Since it isn't, it could be the calling convention, but that _should_ be the same between DMD Linux and GDC.

However, I notice that the asm code assumes a frame pointer in EBP, and maybe GDC isn't creating one. But if the poly unittest passes, then it's quite wierd.

Eg, maybe in GDC, all functions which are 100% asm don't have frame pointers -- the poly unittest would still pass, because EBP would be pointing to the unittest frame pointer, which coincidentally has local variables in the same places (!)

We can test that theory by adding some dummy variables to the poly unittest, eg

real x = 3.1; real x2 = 81.1; const real pq[] = [1.1L, 454, 45, 565]; const real pp[] = [56.1L, 32.7L, 6L];

and then the poly unittest should segfault.

If so, changing the version(D_InlineAsm_X86) to version(DigitalMars?_D_InlineAsm_X86) should get us going for now.

I'm not sure I understand what you mean - the poly unittest segfault together with all other functions using poly() when using GDC and the asm version, no need to test that further?

Sorry, I'd misinterpreted a comment in another ticket about the poly unittest. It's clear that the asm code for poly() is buggy - it assumes a frame pointer in EBP, but the ABI spec does not mandate the use of frame pointers. In which case, using Phobos, the poly unittest should also fail with GDC.

-->Phobos bug.

SVN rev 2194 should fix it.

The unittest is now working, see #467 to get a proper asm implementation for poly.