<div dir="ltr"><div>Most likely it is your GTK+ theme. Many GTK+ themes and theme engines abuse floating point calculations which go unnoticed normally since the vast majority of C/C++ programs do not check for them. The solution is to do something like (IIRC):<br>
<br><pre>SetExceptionMask([]);</pre><br>Which disables all floating point exceptions. Alternatively switch to a theme that doesn't mess FP calculations, bu you can't guarantee that your users will have it.<br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 7, 2013 at 10:04 AM, Xiangrong Fang <span dir="ltr"><<a href="mailto:xrfang@gmail.com" target="_blank">xrfang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div class="gmail_quote">2013/3/7 leledumbo <span dir="ltr"><<a href="mailto:leledumbo_cool@yahoo.co.id" target="_blank">leledumbo_cool@yahoo.co.id</a>></span><br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Because setting the mask means telling the processor to generate (or not to<br>
generate? I forgot) SIGFPE for the given operations. e.g. exZeroDivide may<br>
trigger SIGFPE if there's a division by zero with floating point operation.<br>
How to trace? You already get it, the program will report the line that<br>
causes it, you can directly go to the respective line to see what happens.<br>
But this requires that the code lies in the program space (not in external<br>
library) and the code is compiled with runtime error backtrace (-gl).<br>
Otherwise, the program can only report as deep as it can find.<br></blockquote></div><br></div>I don't understand:<br><br>1) even if I set the masks, why an empty LCL application generate SIGFPE? It means that somewhere GTK or whatever library *indeed* do things like 1/0, only that they are normally hidden/not reported?<br>


<br>2) I already found the problem in my code which is a like look like: <br><br><b><span style="font-family:courier new,monospace">if tbLog.Down then Y := exp(Y);</span></b><br><br>And Y is a big number e.g. 2500, which caused floating point overflow.    The problem was that the number itself should be Log()ed, so that exp() only restore its original value.   That was my bug, but the weird thing is that SIGFPE is generated in unit LCLType on the line that set font height, which is very innocent, and after I commented out the font.Height operation, the SIGFPE slipped to somewhere else, but NEVER on the line that generated it!   <br>


<br>Could you explain why? and how to locate where the SIGFPE occurred?<br><br>Thanks!<br><br><br>
<br>--<br>
_______________________________________________<br>
Lazarus mailing list<br>
<a href="mailto:Lazarus@lists.lazarus.freepascal.org">Lazarus@lists.lazarus.freepascal.org</a><br>
<a href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus" target="_blank">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a><br>
<br></blockquote></div><br></div>