Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Dec 18, 2004 11:26 pm Post subject:
Been doing some trawling through the java apple mailing lists for things on apple events and found this strange gem of a property suggestion:
com.apple.mrj.deferAppleEventHandling=true
I don't know what it does, don't think it'd be wise to try, but it does seem to tell me that there are some strange things afoot with AppleEvents and the old Carbon based VMs.
At this point, the only things that I have left to do to release Neo/J 1.1 Beta are to create the language pack installers (there are 40 languages in OOo 1.1.3!) and wait for the updated Finder icons from Smokey.
Everything under control, then . Except for bug 209 ...
OK, it's official: bug 209 is beginning to piss me off
Can you get the file open via dock to happen consistently? I was playing around on my box trying to do opens via the dock icon of single files & multiple files and didn't encounter any issues, but I still don't doubt they exist. I was trying to see if I could get a test case to fire off and examine what's going on.
Did you get any crashes when double clicking docs in the Finder? That too should be sending appleevents, only difference woudl be they're not coming from the Dock.
ed
Hi Ed,
Sorry for the latish response--I've been away from the computer all morning. I haven't been able to duplicate the crash yet in any consistent way, either with dragging the docs to the dock or double-clicking them. After uploading "posttestpatch6bug.txt" to Bug 209 I had another nasty crash (much like the first one I reported as 263), where I had to force-quit from the menu. I think this was just from calling the app to the front and scrolling. I couldn't find the log in Console (?!). I also had a strange incident where the dock icon kept bouncing after NeoJ opened. I was able to quit from the menu with no problem, and the "forever bouncing icon" hasn't come back. Yet I had good stability for some reason with patch 8, and NeoJ with patch 10 has been pretty good on the frankenmac (vs. the iBook G4 at work where I had the crashes).
I know you guys want to wrap this up, but I'm happy to keep running test patches if you have any more. The thing that "bugs" me about this bug is that it's so danged inconsistent.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Dec 19, 2004 1:06 pm Post subject:
I agree that it is frustrating that these crashes are so difficult to reproduce. It makes it all that much harder to report and debug for everyone
With Patrick's help, I just committed some new code that allows us to handle open and print appleevents directly, bypassing the virtual machine's apple event dispatching voodoo (that Process() function in all the traces). This should be in a forthcoming patch.
As to the scrolling issue, that one I'm unaware of as I've been in appleevent hell myself
With Patrick's help, I just committed some new code that allows us to handle open and print appleevents directly, bypassing the virtual machine's apple event dispatching voodoo (that Process() function in all the traces). This should be in a forthcoming patch.
I hope that makes tracking a bit easier. Anyway, I had another little accident. I just put that in bug 268 as it looked different and I didn't feel like comparing to old crashlogs.
I hope this is a little bug and not a monstrous Alien like 209..
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Dec 19, 2004 1:53 pm Post subject:
While the circumstances are different, I did just mark it as a duplicate of 209 as the crash itself is inside the Java virtual machine's appleevent handler. As per the recently checked in changes I made, the VM's stuff should never get called any longer, so the set of circumstances leading up to this one shouldn't crash either
While the circumstances are different, I did just mark it as a duplicate of 209 as the crash itself is inside the Java virtual machine's appleevent handler. As per the recently checked in changes I made, the VM's stuff should never get called any longer, so the set of circumstances leading up to this one shouldn't crash either
OK, hit me with that new patch, then <G>. A pity about all the earlier (attempts at) fixes, though...
A pity about all the earlier (attempts at) fixes, though...
This is pretty much standard for most hard to fix bugs. Come up with a hypothesis, write code, test, repeat many times until you find a hypothesis that works.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Dec 19, 2004 2:15 pm Post subject:
Not to mention having to exorcise bugs that are occurring in other people's code (*COUGH* Apple Virtual Machine */COUGH*) to which we don't have source to see what might even be causing the problem. Shooting in the dark is frustrating, especially when circumstances make it the only possible debugging method
Not to mention having to exorcise bugs that are occurring in other people's code (*COUGH* Apple Virtual Machine */COUGH*) to which we don't have source to see what might even be causing the problem. Shooting in the dark is frustrating, especially when circumstances make it the only possible debugging method .
Back in the old Amiga days I used AMOS for a while. That was programming *around* the bugs. Nowadays, using M$ software is like that, day in, day out, for the unfortunate slobs that have to use that. I remember putting together a *big* spreadsheet in Excel a few years back.
Imagine the frustration when you don't have the skill to make replacement code. There's a reason why we love you guys .
Not to mention having to exorcise bugs that are occurring in other people's code (*COUGH* Apple Virtual Machine */COUGH*) to which we don't have source to see what might even be causing the problem. Shooting in the dark is frustrating, especially when circumstances make it the only possible debugging method
ed
???
did you open a bug report at bugreport.apple.com ?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Dec 19, 2004 6:07 pm Post subject:
I didn't bother filing a bug report as the 1.3.1 virtual machine is essentially end-of-lifed, having been replaced by 1.4.x which due to a number of reasons can't yet be used with NeoJ. Anything I file against 1.3.1 would probably be blissfully ignored by the Java team just like how we mark OOo bugs as "won't fix"
The essential difficulty is that NeoJ isn't really Java but actually Java+Carbon (like the 1.3.1 virtual machine). Apple's 1.4 and later virtual machiens are Java+Cocoa, so moving will definitely require non-trivial work.
I left patch11 running on the 2 machines at work; NeoJ crashed on the iBook G4 but is still running on the Powermac 450 with many large files open. I uploaded the crash log to Bugzilla as "patch11crash.txt."
I had been away from the computer for an hour or so, came back to the iBook and tried to call NeoJ (which had been hidden) from the Dock, but it would not come forward. By hiding the frontmost apps I saw that NeoJ had a spinning beach ball and needed to be force quit.
Another observation, probably unrelated. Sometimes, especially when NeoJ is not running, if I drag a large .txt file to the dock icon, NeoJ opens and gives me an ASCII dialogue box that is blank (white). I cannot escape out of it and must force quit. When NeoJ is already open it will sometimes give me the ASCII dialogue with the buttons intact. Have you seen this before?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
. Except for bug 209 
...
