macOS Exception handling of Java plugin crash.

[Marimuthu]

Dear All,

I have an web based application through which I I load an web page which contains Java applets(actually the url is that of Juniper VPN). Everything worked fine until the update.
I find that after the latest update of 10.6.8, this also updates the Java Plugin to 1.6.0_29, the applet/plug-in crashes.

I have attached the project where the plug-in crash for your kind reference.

Could you please let me know as to how do i handle the exception/Exception from occurring. I am not aware of methods of exception handling hence requesting you to please help me with the same.

When I try loading the crash causing URL on Safari, it does not crash as I guess the browser is handling it. Though I get the following warning in the console with I try this with the Safari browser.

11/11/11 9:39:03 PM	[0x0-0x28028].com.apple.Safari[816]	2011-11-11 21:39:03.470 PluginProcess[1031:903] NPP_New: *** +[WebPluginDatabase installedPlugins]: unrecognized selector sent to class 0xa001441c

Here is the call stack of the crash observed in the application console when my application crashes.

Exception in thread "AWT-AppKit" netscape.javascript.JSException: Plugin instance for applet ID 1 was already released
	at sun.plugin2.main.server.LiveConnectSupport.getInfo(LiveConnectSupport.java:405)
	at sun.plugin2.main.server.LiveConnectSupport.shutdown(LiveConnectSupport.java:41)
	at sun.plugin2.main.server.JVMInstance.unregisterApplet(JVMInstance.java:1376)
	at sun.plugin2.main.server.JVMInstance.recycleAppletID(JVMInstance.java:390)
	at sun.plugin2.main.server.JVMManager.recycleAppletID(JVMManager.java:360)
	at sun.plugin2.main.server.MozillaPlugin.stopApplet(MozillaPlugin.java:302)
	at sun.plugin2.main.server.MozillaPlugin.destroy(MozillaPlugin.java:207)
objc[59297]: FREED(id): message layerDidBecomeVisible: sent to freed object=0x14f1b370
Invalid memory access of location 0x0 eip=0x986644fd

Below is the extract of the Crash report when the application crash. This info was collected on a different instance of java plugin crash.

Process:         MiniBrowser [60232]
Path:            /Users/Marimuthu/Desktop/VPN Crash/MiniBrowser/build/Debug/MiniBrowser.app/Contents/MacOS/MiniBrowser
Identifier:      com.apple.MiniBrowser
Version:         1.0 (1)
Code Type:       X86 (Native)
Parent Process:  launchd [108]

Date/Time:       2011-11-16 10:47:41.231 +0530
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          2697621 sec
Crashes Since Last Report:           82
Per-App Interval Since Last Report:  21196 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      0D964075-F5A7-4F46-A2C8-F4F158BC0FA2

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Java: AWT-AppKit  Dispatch queue: com.apple.main-thread

Application Specific Information:
objc_msgSend() selector name: setAppletError:

Java information:
 Exception type: Bus Error (0xa) at pc=000000009865af8b
 
 Java VM: Java HotSpot(TM) Client VM (20.4-b02-402 mixed mode, sharing macosx-x86)
 
Current thread (0000000016002000):  JavaThread "AWT-AppKit" [_thread_in_native, id=-1598094016, stack(00000000bf800000,00000000c0000000)]
Stack: [00000000bf800000,00000000c0000000]
 
Java Threads: ( => current thread )
  000000001904a800 JavaThread "AWT-Shutdown" [_thread_blocked, id=-1314721792, stack(00000000b192f000,00000000b1a2f000)]
  0000000016041c00 JavaThread "JVM[id=1]-Heartbeat" [_thread_blocked, id=-1315778560, stack(00000000b182d000,00000000b192d000)]
  000000001605cc00 JavaThread "JRE 1.6.0.29 Worker Thread" [_thread_blocked, id=-1316835328, stack(00000000b172b000,00000000b182b000)]
  000000001605bc00 JavaThread "JRE 1.6.0.29 Output Reader Thread" [_thread_in_native, id=-1317892096, stack(00000000b1629000,00000000b1729000)]
  000000001605ac00 JavaThread "JRE 1.6.0.29 Output Reader Thread" [_thread_in_native, id=-1318948864, stack(00000000b1527000,00000000b1627000)]
  0000000016059c00 JavaThread "Thread-3" [_thread_blocked, id=-1320005632, stack(00000000b1425000,00000000b1525000)]
  0000000016059000 JavaThread "process reaper" daemon [_thread_in_native, id=-1321062400, stack(00000000b1323000,00000000b1423000)]
  0000000016046000 JavaThread "Java Plug-In Pipe Worker Thread (Server-Side)" daemon [_thread_in_native, id=-1322119168, stack(00000000b1221000,00000000b1321000)]
  0000000016040400 JavaThread "Poller SunPKCS11-Darwin" daemon [_thread_blocked, id=-1324232704, stack(00000000b101d000,00000000b111d000)]
  000000001604d000 JavaThread "traceMsgQueueThread" daemon [_thread_blocked, id=-1325289472, stack(00000000b0f1b000,00000000b101b000)]
  0000000016024400 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=-1328799744, stack(00000000b0bc2000,00000000b0cc2000)]
  0000000016023400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=-1329856512, stack(00000000b0ac0000,00000000b0bc0000)]
  0000000016022400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=-1332117504, stack(00000000b0898000,00000000b0998000)]
  0000000016020400 JavaThread "Finalizer" daemon [_thread_blocked, id=-1333174272, stack(00000000b0796000,00000000b0896000)]
  000000001601f400 JavaThread "Reference Handler" daemon [_thread_blocked, id=-1334231040, stack(00000000b0694000,00000000b0794000)]
=>0000000016002000 JavaThread "AWT-AppKit" [_thread_in_native, id=-1598094016, stack(00000000bf800000,00000000c0000000)]
Other Threads:
  000000001601ec00 VMThread [stack: 00000000b043f000,00000000b053f000] [id=-1336676352]
  0000000019009000 WatcherThread [stack: 00000000b0d9b000,00000000b0e9b000] [id=-1326862336]
 
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
 
Heap
 def new generation   total 4928K, used 4199K [0000000034810000, 0000000034d60000, 0000000035d60000)
  eden space 4416K,  95% used [0000000034810000, 0000000034c29e50, 0000000034c60000)
  from space 512K,   0% used [0000000034c60000, 0000000034c60000, 0000000034ce0000)
  to   space 512K,   0% used [0000000034ce0000, 0000000034ce0000, 0000000034d60000)
 tenured generation   total 10944K, used 0K [0000000035d60000, 0000000036810000, 0000000038810000)
   the space 10944K,   0% used [0000000035d60000, 0000000035d60000, 0000000035d60200, 0000000036810000)
 compacting perm gen  total 12288K, used 1469K [0000000038810000, 0000000039410000, 000000003c810000)
   the space 12288K,  11% used [0000000038810000, 000000003897f548, 000000003897f600, 0000000039410000)
    ro space 20480K,  50% used [000000003c810000, 000000003d212490, 000000003d212600, 000000003dc10000)
    rw space 20480K,  61% used [000000003dc10000, 000000003e853838, 000000003e853a00, 000000003f010000)
 
Code Cache  [0000000016801000, 000000001689a000, 0000000018801000)
 total_blobs=262 nmethods=101 adapters=105 free_code_cache=32927872 largest_free_block=0
 
Virtual Machine Arguments:
JVM Args: -Xbootclasspath/a:/System/Library/Frameworks/JavaVM.framework/Resources/Deploy.bundle/Contents/Resources/Java/deploy.jar:/System/Library/Frameworks/JavaVM.framework/Resources/Deploy.bundle/Contents/Resources/Java/javaws.jar:/System/Library/Frameworks/JavaVM.framework/Resources/Deploy.bundle/Contents/Resources/Java/plugin.jar -Xmx64m -Djava.awt.headless=true -XX:+UseSerialGC -XX:MaxDirectMemorySize=64m 
Java Command: <unknown>
Launcher Type: generic
Physical Memory: Page Size = 4k, Total = 3840M, Free = 11M
 

Thread 0 Crashed:  Java: AWT-AppKit  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x9865af8b objc_msgSend + 27
1   JavaNativeFoundation          	0x14aa9ff1 +[JNFRunLoop _performCopiedBlock:] + 16
2   com.apple.Foundation          	0x9a2be711 __NSThreadPerformPerform + 506
3   com.apple.CoreFoundation      	0x97fb045b __CFRunLoopDoSources0 + 1563
4   com.apple.CoreFoundation      	0x97fadf1f __CFRunLoopRun + 1071
5   com.apple.CoreFoundation      	0x97fad3f4 CFRunLoopRunSpecific + 452
6   com.apple.CoreFoundation      	0x97fad221 CFRunLoopRunInMode + 97
7   com.apple.HIToolbox           	0x93da2e04 RunCurrentEventLoopInMode + 392
8   com.apple.HIToolbox           	0x93da2bb9 ReceiveNextEventCommon + 354
9   com.apple.HIToolbox           	0x93da2a3e BlockUntilNextEventMatchingListInMode + 81
10  com.apple.AppKit              	0x9175d595 _DPSNextEvent + 847
11  com.apple.AppKit              	0x9175cdd6 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
12  com.apple.AppKit              	0x9171f1f3 -[NSApplication run] + 821
13  com.apple.AppKit              	0x91717289 NSApplicationMain + 574
14  com.apple.MiniBrowser         	0x00001a8c main + 30 (main.m:46)
15  com.apple.MiniBrowser         	0x00001a42 start + 54

 

[Marimuthu]

The crash that I state above can also be reproducible by specifying the following URL in the MiniBrowser App. The test URL is http://www.chemaxon.com/marvin/sketch/index.php

You will notice in the console the following warning and then the crash.

2011-11-16 13:49:56.195 MiniBrowser[61877:a0f] Process manager already initialized -- can't fully enable headless mode.
Invalid memory access of location 0x0 eip=0x9865af8b

Program received signal:  “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all
kill
quit

 

[Marimuthu]

Figured out the cause of the crash.

It happens when you application is build using 32-Bit Intel Architecture.
If i switch to 64-Bit Intel Architecture and build the project, the issue goes away.


As my application is built using 32-bit architecture (don't want it to be 64-bit for various reasons), i plan to create an separate 64-bit standalone application where I launch the WebView (which loads the webpage containing the Java applet).
I would then load this 64bit app from my 32-bit main application and use distributed notification for communication between these 2 processes.

As i am relatively new to Cocoa, would like to know if I can achieve the above mentioned i.e. if is possible for an 32-bit application to load/run/interact an 64-bit application?

 

[jiminaus]

is possible for an 32-bit application to load/run/interact an 64-bit application?

Yes, these no problem doing this either way. In fact it's a common solution to keeping around legacy 32-bit components in the larger context of a 64-bit app.

 

[Marimuthu]

Hi jiminaus,

Thanks for the reply.

Could experts please throw some light as to how I should go about implementing the above mentioned requirement?
A sample project which also demonstrates inter process communication will be of great help.

Thanks & Regards.

 

[chown33]

Could experts please throw some light as to how I should go about implementing the above mentioned requirement?
A sample project which also demonstrates inter process communication will be of great help.

It's the same as any other inter-process communication. Nothing is different in that area.

The only difference is in how you compile the executables. In one case, compile for 32-bit only. In the other case, compile for 64-bit only. All the same APIs, strategies, etc. are otherwise identical. If each program only has one architecture, then you don't even need to specify which arch to run; there's only one choice in each case.

The only thing you should watch out for is stupid things like assuming the size of certain types. This kind of problem isn't unique to 64-bit vs. 32-bit though. For example, pointers only apply to one process anyway, so passing a pointer between processes is stupid even when everything is 32-bit.

You already mentioned distributed notifications, so look up the relevant class (the distributed notification center). There should be at least one link to sample code, probably nearby the words "sample code". You should probably look up inter process communication, too; there are more options than just distributed notifications (e.g. unix domain sockets, pipes, tcp/ip sockets (loopback interface), signals, etc.).

I also recommend making a simple test case. For example using distributed notifications. Make one executable 32-bit, the other 64-bit. Run them. Confirm that they can communicate using identical APIs. If you have specific problems, post specific questions. If you don't have problems, then don't manufacture them from Worry Dust.