Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Dan Sugalski [EMAIL PROTECTED] wrote: And the issue of what happens when we're running threaded and the wrong thread gets the signal. (Figuring out which thread gets notified of a signal in general is going to be... fun) Yep, that's a problem. The plan is, to configure that per platform. *If* the platform signals SIGFPE on integer divide by zero and delivers the signal in a known way (e.g. to the offending thread), we can use it, and save the explicit if-its-zero-check. leo
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
At 10:24 PM -0800 12/22/03, Jeff Clites wrote: On Dec 22, 2003, at 6:57 AM, Dan Sugalski wrote: At 11:44 AM -0800 12/20/03, Jeff Clites wrote: On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. Ah, good take. As Perl5 obviously catches div by 0, we probably need some Configure test, if a platform signals int div/0. I was told that int divide by zero has undefined behavior in C (though it's well-defined for floating-point operations, via IEEE 754), so it might be safest to always do an actual check in parrot (though that's an extra conditional branch around every int divide). What I'm thinking is that for a particular platform the behavior may not be consistent, so an accurate Configure check might be difficult. (Also, having this always directly raise a parrot exception should leave us with less platform-dependent code--e.g. I assume the Windows case wouldn't use signals.) I don't want to use signals to catch math errors. (Though, amusingly, fatal hardware-type errors like math issues were what signals were originally for. But that's something for another time) It's platform-dependent, as we've seen some platforms don't do it, and worse yet some platforms are somewhat indeterminate as to when the errors get thrown. (The Alpha has fuzzy math exceptions. The math screwed up status bit does get set, but it isn't generally checked immediately, and the massively out-of-order execution engine tends to throw them at what looks like odd times) Math operations that can throw errors should have a wrapper around them to catch the error, either a macro or some ops preprocessing keyword that we can wedge in platform-specific checks for. Another good reason to not use signals to catch math errors is that it's bad practice for libraries to install signals handlers as part of their basic operation (since signal handlers are global to the application, you unexpectedly affect the global behavior of the app). And the issue of what happens when we're running threaded and the wrong thread gets the signal. (Figuring out which thread gets notified of a signal in general is going to be... fun) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
At 11:44 AM -0800 12/20/03, Jeff Clites wrote: On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. Ah, good take. As Perl5 obviously catches div by 0, we probably need some Configure test, if a platform signals int div/0. I was told that int divide by zero has undefined behavior in C (though it's well-defined for floating-point operations, via IEEE 754), so it might be safest to always do an actual check in parrot (though that's an extra conditional branch around every int divide). What I'm thinking is that for a particular platform the behavior may not be consistent, so an accurate Configure check might be difficult. (Also, having this always directly raise a parrot exception should leave us with less platform-dependent code--e.g. I assume the Windows case wouldn't use signals.) I don't want to use signals to catch math errors. (Though, amusingly, fatal hardware-type errors like math issues were what signals were originally for. But that's something for another time) It's platform-dependent, as we've seen some platforms don't do it, and worse yet some platforms are somewhat indeterminate as to when the errors get thrown. (The Alpha has fuzzy math exceptions. The math screwed up status bit does get set, but it isn't generally checked immediately, and the massively out-of-order execution engine tends to throw them at what looks like odd times) Math operations that can throw errors should have a wrapper around them to catch the error, either a macro or some ops preprocessing keyword that we can wedge in platform-specific checks for. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
On Dec 22, 2003, at 6:57 AM, Dan Sugalski wrote: At 11:44 AM -0800 12/20/03, Jeff Clites wrote: On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. Ah, good take. As Perl5 obviously catches div by 0, we probably need some Configure test, if a platform signals int div/0. I was told that int divide by zero has undefined behavior in C (though it's well-defined for floating-point operations, via IEEE 754), so it might be safest to always do an actual check in parrot (though that's an extra conditional branch around every int divide). What I'm thinking is that for a particular platform the behavior may not be consistent, so an accurate Configure check might be difficult. (Also, having this always directly raise a parrot exception should leave us with less platform-dependent code--e.g. I assume the Windows case wouldn't use signals.) I don't want to use signals to catch math errors. (Though, amusingly, fatal hardware-type errors like math issues were what signals were originally for. But that's something for another time) It's platform-dependent, as we've seen some platforms don't do it, and worse yet some platforms are somewhat indeterminate as to when the errors get thrown. (The Alpha has fuzzy math exceptions. The math screwed up status bit does get set, but it isn't generally checked immediately, and the massively out-of-order execution engine tends to throw them at what looks like odd times) Math operations that can throw errors should have a wrapper around them to catch the error, either a macro or some ops preprocessing keyword that we can wedge in platform-specific checks for. Another good reason to not use signals to catch math errors is that it's bad practice for libraries to install signals handlers as part of their basic operation (since signal handlers are global to the application, you unexpectedly affect the global behavior of the app). (In this particular case, a math error in some non-parrot-related part of an application would end up trying to throw a parrot exception) JEff
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Jeff Clites [EMAIL PROTECTED] wrote: The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. Ah, good take. As Perl5 obviously catches div by 0, we probably need some Configure test, if a platform signals int div/0. I'm not sure of the best way to fix the tests Could your try float division? JEff leo
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. Ah, good take. As Perl5 obviously catches div by 0, we probably need some Configure test, if a platform signals int div/0. I was told that int divide by zero has undefined behavior in C (though it's well-defined for floating-point operations, via IEEE 754), so it might be safest to always do an actual check in parrot (though that's an extra conditional branch around every int divide). What I'm thinking is that for a particular platform the behavior may not be consistent, so an accurate Configure check might be difficult. (Also, having this always directly raise a parrot exception should leave us with less platform-dependent code--e.g. I assume the Windows case wouldn't use signals.) I'm not sure of the best way to fix the tests Could your try float division? That doesn't cause SIGFPE either. And actually this: set N10, 2.1 div N10, 0 print N10 end prints inf. Some more data: The behavior in these 2 cases matches the behavior of analogous C code on Mac OS X, as you'd expect. Also, on Intel--don't remember if this was Windows or Linux--float divide by zero in a C test case also gave inf via printf. I believe that the IEEE default behavior is to not raise a signal for invalid operations. JEff
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Leo wrote: Please try something like this: $ gdb parrot (gdb) b sig_handler (gdb) r t/op/hacks_1.pasm Program received signal SIGFPE, Arithmetic exception. [ ... ] (gdb) s Breakpoint 1, sig_handler (signum=8) at src/events.c:33 [ some more steps ] 332 longjmp(the_exception.destination, 1); (gdb) runops (interpreter=0x823df48, offset=0) at src/interpreter.c:632 (gdb) b sig_handler Breakpoint 1 at 0xed5e0: file src/events.c, line 33. (gdb) r t/op/hacks_1.pasm Starting program: /Users/allison/projects/cvs/parrot/parrot t/op/hacks_1.pasm Reading symbols for shared libraries . done not reached Program exited normally. (gdb) Allison
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
On Dec 17, 2003, at 11:24 AM, Leopold Toetsch wrote: Allison Randal [EMAIL PROTECTED] wrote: $ parrot t/op/hacks_1.pasm not reached ... Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE? Is PARROT_HAS_HEADER_SIGNAL defined? Yes to both questions. The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. I'm not sure of the best way to fix the tests--long-term I'd expect we'd want parrot to explicitly guard against divide-by-zero (as perl5 seems to do), but I know that's not the real point of these tests. JEff
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Leo wrote: Very likely that SIGFPE isn't defined. Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE? (line 14) .constant SIGFPE8 Is PARROT_HAS_HEADER_SIGNAL defined? (Finclude/parrot/has_header.h: line 46) define PARROT_HAS_HEADER_SIGNAL 1 Allison
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Allison Randal [EMAIL PROTECTED] wrote: Excellent. It compiles now. I do have two failing tests which may be related (catching SIGFPE): Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/hacks.t2 512 22 100.00% 1-2 Could you please run these 2 standalone: $ parrot t/op/hacks_1.pasm catched it error -8 severity 0 $ parrot t/op/hacks_2.pasm catched it ok leo
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Leo wrote: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/hacks.t2 512 22 100.00% 1-2 Could you please run these 2 standalone: $ parrot t/op/hacks_1.pasm catched it error -8 severity 0 $ parrot t/op/hacks_2.pasm catched it ok $ parrot t/op/hacks_1.pasm not reached $ parrot t/op/hacks_2.pasm not reached $ Allison
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Allison Randal [EMAIL PROTECTED] wrote: $ parrot t/op/hacks_1.pasm not reached Very likely that SIGFPE isn't defined. Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE? Is PARROT_HAS_HEADER_SIGNAL defined? Allison leo
[perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
# New Ticket Created by Allison Randal # Please include the string: [perl #24682] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24682 I can't compile parrot on Mac OS 10.3.1 tonight. It's been about a week since I last compiled it, so it's a fairly recent change. The error message just before the compile dies is: ... fastcall.o pcc.o cc -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm ld: warning -L: directory name (/usr/local/lib) does not exist ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _Parrot_set_sighandler make: *** [parrot] Error 1 I also get this error several times when I run Configure.pl with --verbose: ld: warning -L: directory name (/usr/local/lib) does not exist (I can send the captured output from Configure.pl if anyone's interested.) I don't have a /usr/local/lib in 10.3.1. My 10.2.x drive does have a /usr/local/lib, and it contains: libdl.a and libdl.dylib. In 10.3.1, libdl.dylib lives in /usr/lib. I haven't found libdl.a. Allison
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
On Tue, Dec 16, 2003 at 11:54:27PM -0500, Dan Sugalski wrote: At 12:00 AM + 1/1/04, Allison Randal (via RT) wrote: # New Ticket Created by Allison Randal # Please include the string: [perl #24682] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24682 I can't compile parrot on Mac OS 10.3.1 tonight. It's been about a week since I last compiled it, so it's a fairly recent change. The error message just before the compile dies is: ... fastcall.o pcc.o cc -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm ld: warning -L: directory name (/usr/local/lib) does not exist ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _Parrot_set_sighandler make: *** [parrot] Error 1 Try resync-ing with CVS, then reconfigure and build. The events patch added more platform-dependent signal handling to parrot, and the darwin files didn't get updated. (Since fixed) Excellent. It compiles now. I do have two failing tests which may be related (catching SIGFPE): Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/hacks.t2 512 22 100.00% 1-2 25 subtests skipped. Failed 1/59 test scripts, 98.31% okay. 2/1001 subtests failed, 99.80% okay.
