Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2005-08

MacOSX: EXC_ARITHMETIC in PerformHIConversion

11 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marc Weustink

Hi,

I don't know if it is FCP problem, it looks like it is, but I can't see how.

In XCode i've created a Carbon app with the given in main.c. When running this, everything works as expected. However when I replace Hello.app/Contents/MacOS/Hello with a version created by FPC from hello.pp, I get an exception when I hover with the mouse over the Hello
- Services - FileMerge menuitem (this is an empty submenu) Now what I don't get is what this has to do with the fpc generated exe. AFAIK this menu is handled by the OS internally.
Am I missing something ? Am I not allowed to change the exe ? Or is it something FPC had to compile in the exe but didn't do ?

Anyone any clue ?

TIA, Marc

--- main.c ---
#include <Carbon/Carbon.h>
int main(int argc, char* argv[])
{
     WindowRef   window;
     OSStatus	err;
     Rect        R;
     R.top = 50; R.left = 50; R.right = 500; R.bottom = 200;
     err = CreateNewWindow(
       kDocumentWindowClass,
       kWindowStandardDocumentAttributes |
       kWindowStandardHandlerAttribute |
       kWindowInWindowMenuAttribute,
       &R, &window);
     require_noerr( err, CantCreateWindow );
     // The window was created hidden so show it.
     ShowWindow( window );
     // Call the event loop
     RunApplicationEventLoop();

CantCreateWindow:

	return err;

}

--- hello.pp ---
program FPCCarbon;
{$mode objfpc}
uses
   Carbon;
label
   CantCreateWindow;
var
   R       : Rect;
   err     : OSStatus;
   window  : WindowRef;
begin
     R.Top := 50; R.Left := 50; R.Right := 500; R.Bottom := 200;
     err := CreateNewWindow(
       kDocumentWindowClass,
       kWindowStandardDocumentAttributes or
       kWindowStandardHandlerAttribute or
       kWindowInWindowMenuAttribute,
       R, window);
     if err  noErr then
         goto CantCreateWindow;
     // The window was created hidden so show it.
     ShowWindow(window);
     // Call the event loop
     RunApplicationEventLoop;
     // Error Handling
CantCreateWindow:
     Halt(err);
end.

Reply by email

Jonas Maebe
to Marc Weustink
Marc Weustink wrote 8 lines
In XCode i've created a Carbon app with the given in main.c. When running this, everything works as expected. However when I replace Hello.app/Contents/MacOS/Hello with a version created by FPC from hello.pp, I get an exception when I hover with the mouse over the Hello - Services - FileMerge menuitem (this is an empty submenu) Now what I don't get is what this has to do with the fpc generated exe. AFAIK this menu is handled by the OS internally. Am I missing something ?

There is a bug in the Carbon framework under Mac OS X 10.4.x which causes it to generate invalid floating point operation exceptions in some cases. You can work around it by disabling these exceptions, using the following piece of code (just add it at the start of your main program)

   asm
     mtfsfi 6,1
   end;

Jonas

Reply by email

Marc Weustink
to Jonas Maebe
Jonas Maebe wrote 22 lines
On 14 aug 2005, at 17:40, Marc Weustink wrote: > In XCode i've created a Carbon app with the given in main.c. When > running this, everything works as expected. However when I replace > Hello.app/Contents/MacOS/Hello with a version created by FPC from > hello.pp, I get an exception when I hover with the mouse over the > Hello - Services - FileMerge menuitem (this is an empty submenu) > Now what I don't get is what this has to do with the fpc generated > exe. AFAIK this menu is handled by the OS internally. > Am I missing something ? There is a bug in the Carbon framework under Mac OS X 10.4.x which causes it to generate invalid floating point operation exceptions in some cases. You can work around it by disabling these exceptions, using the following piece of code (just add it at the start of your main program) asm mtfsfi 6,1 end;

OK, thanks. I'm indeed using 10.4.2.

Are these exceptions by default disabled by gcc ?

Marc

Reply by email

Jonas Maebe
to Marc Weustink
Marc Weustink wrote
Are these exceptions by default disabled by gcc ?

The FPC runtime explicitly turns them on by default (since they are required for detecting errors), while libc doesn't. It is independent of the compiler used.

Jonas

Reply by email

Marc Weustink
to Jonas Maebe
Jonas Maebe wrote 9 lines
On 15 Aug 2005, at 17:47, Marc Weustink wrote: > Are these exceptions by default disabled by gcc ? The FPC runtime explicitly turns them on by default (since they are required for detecting errors), while libc doesn't. It is independent of the compiler used.

So, if I understand it correct, you wont get a aritmic exeption in FPC anymore when this is turned on ?

(and since it is off by default, what are the chances that it get fixed ?)

Marc

Reply by email

Jonas Maebe
to Marc Weustink
Marc Weustink wrote 9 lines
>> Are these exceptions by default disabled by gcc ? > > The FPC runtime explicitly turns them on by default (since they > are required for detecting errors), while libc doesn't. It is > independent of the compiler used. > So, if I understand it correct, you wont get a aritmic exeption in FPC anymore when this is turned on ?

The "invalid fpu operation" exceptions are turned on in the FPC system unit initialisation code. If you add the code I posted, they are turned off again and so you won't get them (not due to buggy code in the Carbon framework and not anywhere else either).

(and since it is off by default, what are the chances that it get fixed ?)

In the Carbon framework? Reasonable if many people report a bug to Apple with a C program that crashes. At least one person has already done that. The main problem is that this problem does not occur on all systems. For example, it does not happen on my iBook nor on my G5.

Jonas

Reply by email

Marc Weustink
to Jonas Maebe
Jonas Maebe wrote 19 lines
On 15 Aug 2005, at 18:25, Marc Weustink wrote: >>> Are these exceptions by default disabled by gcc ? >> >> >> The FPC runtime explicitly turns them on by default (since they are >> required for detecting errors), while libc doesn't. It is >> independent of the compiler used. >> > > So, if I understand it correct, you wont get a aritmic exeption in > FPC anymore when this is turned on ? The "invalid fpu operation" exceptions are turned on in the FPC system unit initialisation code. If you add the code I posted, they are turned off again and so you won't get them (not due to buggy code in the Carbon framework and not anywhere else either).

That last part I was already afraid of. This would mean that I have to add it to the lcl-carbon initialization code and that no lcp app based on carbon would get the exception. Not the nices solution if you ask me. I'll try to find a way to wrap only the failing call/event.

Show quoted text 8 lines
> (and since it is off by default, what are the chances that it get > fixed ?) In the Carbon framework? Reasonable if many people report a bug to Apple with a C program that crashes. At least one person has already done that. The main problem is that this problem does not occur on all systems. For example, it does not happen on my iBook nor on my G5.

Oh, fun.... :( also not my sample ?)

Marc

Reply by email

Dr. Karl-Michael Schindler
to Marc Weustink

Hi,

I tried the latest revision (1307) of fpc, but it still shows the same bugs:

The following apps are compiled without problems but crash heavily with runtime error when run on macosx and sure enough they ran some time ago.

ide/fp
fv/test/testapp
docs/videoex/ex1

After the crash the settings of the terminal are heavily screwed. I tried stty sane and reset, but it did not completely recover the terminal. Backspace was still like a return.

In addition, all examples of docs/crtex/ are worse than before. The ouput is as if to a file and not to a terminal. I considered the change in isatty, but found that it is not used.

Could someone check on a different target?

Michael Schindler

Reply by email

Dr. Karl-Michael Schindler
to Dr. Karl-Michael Schindler

I narrowed down the revision. Both issues show up when going from 1291 to 1292.

That is the fixes of isatty in rtl/unix/ crt.pp keyboard.pp ttyname.inc video.pp do not work on macosx. Feedback on other systems is still missing

Michael Schindler

Dr. Karl-Michael Schindler wrote 24 lines
Hi, I tried the latest revision (1307) of fpc, but it still shows the same bugs: The following apps are compiled without problems but crash heavily with runtime error when run on macosx and sure enough they ran some time ago. ide/fp fv/test/testapp docs/videoex/ex1 After the crash the settings of the terminal are heavily screwed. I tried stty sane and reset, but it did not completely recover the terminal. Backspace was still like a return. In addition, all examples of docs/crtex/ are worse than before. The ouput is as if to a file and not to a terminal. I considered the change in isatty, but found that it is not used. Could someone check on a different target? Michael Schindler

Reply by email

Jonas Maebe
to Dr. Karl-Michael Schindler
Dr. Karl-Michael Schindler wrote 6 lines
I narrowed down the revision. Both issues show up when going from 1291 to 1292. That is the fixes of isatty in rtl/unix/ crt.pp keyboard.pp ttyname.inc video.pp do not work on macosx. Feedback on other systems is still missing

Fixed.

Jonas

Reply by email

Dr. Karl-Michael Schindler

Hi,

As discussed in the chat, I had a look at the termio unit, in order to move it to the unix dir. The termio.pp files are identical with minor layout differences. So, any of them (bsd or linux) can be moved to unix.

Regarding termiosproc.inc the bsd's were identical (besides the missing 2.0 fixes with inline of netbsd and openbsd). The linux version had already most of bsd. I merged the linux part and the bsd part to a version for the unix dir.

I checked the examples in crtex and the first example in videoex, as well as fv/test/testapp and fp-ide. No problems so far. The merged version of termiosproc.inc is attached for checks and comission.

Best wishes - MiSchi.

Reply by email