-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mincer crash #214
Comments
GDB spam for tvorm: (seems weird, I don't see how one can get SIGFPE from any code in Simplify...)
It crashes also with |
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>.
|
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. |
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>.
|
Actually, SIGFPE can be raised by an integer zero division. https://en.wikipedia.org/wiki/Unix_signal#Relationship_with_hardware_exceptions says
I guess a floating-point number zero division may just give an infinity. |
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>.
|
Valgrind just gave
|
While testing various disk/compression settings with mincer, I get a strange crash:
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 theon,compress,gzip,6;
line intreatgzgz.prc
and addOff compress;
at the top ofcalcdia.frm
.It runs fine with
On Compress;
incalcdia.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.
The text was updated successfully, but these errors were encountered: