I noticed you added a Set8087CW() to fix this problem, but it doesn't work for me, at least on amd64 with trackbar.

I made a simple pure gtk+ C and pascal 1:1 program to test this and found out that setting $1332 or $133f doesn't via math unit (SetExceptionMask(GetExceptionMask + exZeroDivide) however does fix it. It's good enough to do this around gtk_main() too it seems (for the trackbar at least).

I think the best thing to do here is to use the Math unit functions and Set/Unset the exZeroDivide mask before/after gtk_main.

Again, the Set8087CW change didn't fix it on amd64/gtk2 (and possibly introduced various issues for math users).

Ales

Thanks for the hint.
Changed in 15785.

Mattias

Does ut turn of exception for divide by zero completely or just before calling gtk code? IOW, does the following code in a TButton.OnClick event handler show the message? If not, it might be worth to add this the list of 'incompatibilities'.

procedure TForm1.Button1Click(Sender: TObject);
var x, y, z: single;
begin
   x := 3.0; y := 1.0;
   try
     z := (x - y ) / (y - 1.0);
   except
     ShowMessage('Exception occurred');
   end;
end;

Vincent

No. Damn.

About 'before calling gtk':
The bug is triggered in a gtk event. There is no pascal code *before*.

Apparently there is a real div by zero error.

Mattias

I faced similar problem recently in cairo.

Probably is a bug in the gtk theme but is not noticed by the developers because gcc disables this kind of exceptions by default.

The long term solution is to find where in the library the exception occurs and report.

Luiz

Mattias Gaertner wrote / nap?sal(a):

Indeed you do gtk_main() and the crash happens inside. There's no real way of switching these only for the gtk lib apart from rewriting gtk bindings AND all callbacks which is pretty much impossible to synchronize the on/off of it.

Indeed, that's how it seemed. My example project which uses pure gtk2 got that, however the line in the themeengine.so which gdb showed me did not have a /0 argument in it, so I think there's a some sort of "effect delay".

Since I managed to bypass GtkAdjustment there's no risk of wrong record padding etc. so this is defenetly not some sort of wrong sized arguments or somesuch. I think it's basically a bug in gtk/humantheme engine.

Mattias

Ales

Btw. one thing which bothers me is that 100% same fpc and c/gcc gtk2 code resulted in different arguments inside the themeing .so file (I compiled my own debug version with printf()). The arguments were from some gtkadjustment, but not the one used directly by the trackbar.

For some reason FPC code resulted in slightly different values (except one), I have absolutely no idea why since there was a lot of code in between the themeing .so and gtk_main() call.

Ales