Mincer crash

[jodavies]

While testing various disk/compression settings with mincer, I get a strange crash:

Time =      17.38 sec    Generated terms =    4700985
            d65c         Terms in output =    3136630
      Prepare first loop Bytes used      = 1181651608
Program terminating in thread 1 at ACCU2 Line 8 --> 
Floating point exception (core dumped)

This is using the mincer test in the speedtest dir. I can provide the files if you don't have them. The crash happens for #define POW "7" and higher, but ONLY if compression is switched off. I comment out the on,compress,gzip,6; line in treatgzgz.prc and add Off compress; at the top of calcdia.frm.

It runs fine with On Compress; in calcdia.frm.

Sorry, this is probably not a particularly useful bug report. Can someone try to reproduce this? I have the same behavior on more than one machine. FORM 4.2.0.

EDIT: v4.1-20131025 crashes also.

[jodavies]

GDB spam for tvorm: (seems weird, I don't see how one can get SIGFPE from any code in Simplify...)

Time =      22.33 sec    Generated terms =    4700985
            d65c         Terms in output =    3136630
      Prepare first loop Bytes used      = 1181651608
Error while reading scratch file in GetOneTerm (3)
Program terminating in thread 7 at ACCU2 Line 8 --> 

Thread 3 "tvorm-git" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7ffe9e04a700 (LWP 3760)]
0x00000000004d74f4 in Simplify (B=B@entry=0x7ffe340008c0, a=a@entry=0x7ffe34332068, na=na@entry=0x7ffe9e0498e4, 
    b=b@entry=0x7ffe34380288, nb=nb@entry=0x7ffe9e0498d8) at reken.c:555
555                             do { y1 = y2 % y3; y2 = y3; } while ( ( y3 = y1 ) != 0 );
(gdb) bt
#0  0x00000000004d74f4 in Simplify (B=B@entry=0x7ffe340008c0, a=a@entry=0x7ffe34332068, na=na@entry=0x7ffe9e0498e4, 
    b=b@entry=0x7ffe34380288, nb=nb@entry=0x7ffe9e0498d8) at reken.c:555
#1  0x00000000004d846b in MulRat (B=B@entry=0x7ffe340008c0, a=<optimised out>, na=<optimised out>, b=<optimised out>, 
    b@entry=0x7ffe1c2fc4e0, nb=<optimised out>, nb@entry=1, c=c@entry=0x7ffe1c2fc554, nc=0x7ffe9e049974) at reken.c:428
#2  0x00000000004c0b6d in PrepPoly (B=B@entry=0x7ffe340008c0, term=term@entry=0x7ffe1c2fc390, par=par@entry=0) at proces.c:4892
#3  0x00000000004c276a in Generator (B=B@entry=0x7ffe340008c0, term=term@entry=0x7ffe1c2fc390, level=74, level@entry=73)
    at proces.c:3132
#4  0x00000000004ca27d in Deferred (B=B@entry=0x7ffe340008c0, term=term@entry=0x7ffe1c2ae190, level=73) at proces.c:4596
#5  0x00000000004c2692 in Generator (B=B@entry=0x7ffe340008c0, term=term@entry=0x7ffe1c2ae190, level=73) at proces.c:3115
#6  0x00000000004c443f in Generator (B=B@entry=0x7ffe340008c0, term=term@entry=0x7ffe1c2ae110, level=61) at proces.c:3931
#7  0x00000000004c443f in Generator (B=B@entry=0x7ffe340008c0, term=term@entry=0x7ffe1c287010, level=2, level@entry=0) at proces.c:3931
#8  0x0000000000522af5 in RunThread (dummy=<optimised out>) at threads.c:1384
#9  0x00007ffff6e866ba in start_thread (arg=0x7ffe9e04a700) at pthread_create.c:333
#10 0x00007ffff6bbc3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

It crashes also with form (takes 10 mins or so), I will start running with valgrind...

[vermaseren]

Little guess: division by zero. Or: y3 = 0. The main question: how can that happen? Cheers Jos

…

On 7 jul. 2017, at 16:58, Josh Davies ***@***.***> wrote: GDB spam for tvorm: (seems weird, I don't see how one can get SIGFPE from any code in Simplify...) Time = 22.33 sec Generated terms = 4700985 d65c Terms in output = 3136630 Prepare first loop Bytes used = 1181651608 Error while reading scratch file in GetOneTerm (3) Program terminating in thread 7 at ACCU2 Line 8 --> Thread 3 "tvorm-git" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7ffe9e04a700 (LWP 3760)] 0x00000000004d74f4 in Simplify ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe34332068, ***@***.***=0x7ffe9e0498e4, ***@***.***=0x7ffe34380288, ***@***.***=0x7ffe9e0498d8) at reken.c:555 555 do { y1 = y2 % y3; y2 = y3; } while ( ( y3 = y1 ) != 0 ); (gdb) bt #0 0x00000000004d74f4 in Simplify ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe34332068, ***@***.***=0x7ffe9e0498e4, ***@***.***=0x7ffe34380288, ***@***.***=0x7ffe9e0498d8) at reken.c:555 #1 0x00000000004d846b in MulRat ***@***.***=0x7ffe340008c0, a=<optimised out>, na=<optimised out>, b=<optimised out>, ***@***.***=0x7ffe1c2fc4e0, nb=<optimised out>, ***@***.***=1, ***@***.***=0x7ffe1c2fc554, nc=0x7ffe9e049974) at reken.c:428 #2 0x00000000004c0b6d in PrepPoly ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe1c2fc390, ***@***.***=0) at proces.c:4892 #3 0x00000000004c276a in Generator ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe1c2fc390, level=74, ***@***.***=73) at proces.c:3132 #4 0x00000000004ca27d in Deferred ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe1c2ae190, level=73) at proces.c:4596 #5 0x00000000004c2692 in Generator ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe1c2ae190, level=73) at proces.c:3115 #6 0x00000000004c443f in Generator ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe1c2ae110, level=61) at proces.c:3931 #7 0x00000000004c443f in Generator ***@***.***=0x7ffe340008c0, ***@***.***=0x7ffe1c287010, level=2, ***@***.***=0) at proces.c:3931 #8 0x0000000000522af5 in RunThread (dummy=<optimised out>) at threads.c:1384 #9 0x00007ffff6e866ba in start_thread (arg=0x7ffe9e04a700) at pthread_create.c:333 #10 0x00007ffff6bbc3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 It crashes also with form (takes 10 mins or so), I will start running with valgrind... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#214 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxEh2fMjb1OrMHDhAutn2EA-hhtg2xks5sLkeBgaJpZM4ORAVl>.

[jodavies]

Well, those variables are all WORD right? Integer divisions can not cause a SIGFPE. My valgrind run will probably need to go overnight, I will let you know if it shows anything interesting.

[vermaseren]

I do not know which circuits on the chip execute that division, and what exception it sends it into when there is an error like division by zero. I could imagine though that it all sends it to the same interrupt routine. One would have to look at the machine (assembler) code to see which instruction is executed. In the past there were chips that did some of the integer stuff in floating point. Maybe that happens here as well (although I doubt that). Jos

…

On 7 jul. 2017, at 21:12, Josh Davies ***@***.***> wrote: Well, those variables are all WORD right? Integer divisions can not cause a SIGFPE. My valgrind run will probably need to go overnight, I will let you know if it shows anything interesting. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#214 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxEuger_Athe1DTFNkeCv8k6IbZithks5sLoMygaJpZM4ORAVl>.

[tueda]

Actually, SIGFPE can be raised by an integer zero division. https://en.wikipedia.org/wiki/Unix_signal#Relationship_with_hardware_exceptions says

For example, if a process attempted integer divide by zero on an x86 CPU, a divide error exception would be generated and cause the kernel to send the SIGFPE signal to the process.

I guess a floating-point number zero division may just give an infinity.

[vermaseren]

From asm-generic/siginfo.h /* * SIGFPE si_codes */ #define FPE_INTDIV (__SI_FAULT|1) /* integer divide by zero */ #define FPE_INTOVF (__SI_FAULT|2) /* integer overflow */ #define FPE_FLTDIV (__SI_FAULT|3) /* floating point divide by zero */ #define FPE_FLTOVF (__SI_FAULT|4) /* floating point overflow */ #define FPE_FLTUND (__SI_FAULT|5) /* floating point underflow */ #define FPE_FLTRES (__SI_FAULT|6) /* floating point inexact result */ #define FPE_FLTINV (__SI_FAULT|7) /* floating point invalid operation */ #define FPE_FLTSUB (__SI_FAULT|8) /* subscript out of range */ #define NSIGFPE 8 This seems to indicate that SIGFPE is a generic flag, covering 8 cases. Jos

…

On 7 jul. 2017, at 21:24, Takahiro Ueda ***@***.***> wrote: Actually, SIGFPE can be raised by an integer zero division. https://en.wikipedia.org/wiki/Unix_signal <https://en.wikipedia.org/wiki/Unix_signal> says For example, if a process attempted integer divide by zero on an x86 CPU, a divide error exception would be generated and cause the kernel to send the SIGFPE signal to the process. I guess a floating-point number zero division may just give an infinity. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#214 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxElF5HJacrjt3zwE0X3fP9Gd36Ycnks5sLoYKgaJpZM4ORAVl>.

[jodavies]

Valgrind just gave

Time =   21142.30 sec    Generated terms =    4700985
            d65c         Terms in output =    3136630
      Prepare first loop Bytes used      = 1181651608
==20395== Warning: set address range perms: large range [0x572af040, 0x74f85540) (defined)
==20395== Warning: set address range perms: large range [0x572af040, 0x74f85540) (defined)
Program terminating at ACCU2 Line 8 -->
==20395== Invalid read of size 4
==20395==    at 0x506556: Crash (tools.c:3711)
==20395==    by 0x4EB9DE: Terminate (startup.c:1707)
==20395==    by 0x4EC0E6: onErrSig (startup.c:1476)
==20395==    by 0x5BAA4AF: ??? (in /lib/x86_64-linux-gnu/libc-2.23.so)
==20395==    by 0x4CCE0A: Simplify (reken.c:553)
==20395==    by 0x4CDC5D: MulRat (reken.c:428)
==20395==    by 0x4B8109: PrepPoly (proces.c:4892)
==20395==    by 0x4B9BDC: Generator (proces.c:3132)
==20395==    by 0x4C0944: Deferred (proces.c:4596)
==20395==    by 0x4B9B1C: Generator (proces.c:3115)
==20395==    by 0x4BB2B7: Generator (proces.c:3931)
==20395==    by 0x4BB2B7: Generator (proces.c:3931)
==20395==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==20395==
  21144.36 sec out of 21146.09 sec