Jump to content
Server Maintenance This Week. ×

java.lang.threaddeath


This topic is 3144 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi all,

Users are reporting an error in FileMaker that looks to be caused by SuperContainer.

While on a layout that has a SuperContainer, a popup error message displays with: "java.lang.threaddeath". The user then cannot close this window and has to force quit FileMaker.

We are running the latest SC, 2.744 on Mac OS 10.6.3 Server in standalone mode.

All users that have experienced the error are running the latest version of Mac OS 10.4 or 10.5 will all secondary updates installed. All users also have the latest SuperContainer and ScriptMaster plugins installed.

Also, one user reported the same error while using Safari to view an IWP page that has SuperContainers on the layout - so the error is not just limited to FileMaker.

This is a new error that we have never experienced before, and we've been using SC for 2 years now. We did just recently update to the latest version of SC.

Anyone else having this issue? Did a search of the forum and I did not see a post with this error listed.

Thanks,

Jerremy

Link to comment
Share on other sites

was just coming here to post about this very error. We have at least a couple users that experience this same crash. We recently upgraded to FM11, though I'm uncertain if this was happening in FM10 or not. I do not experience this error on my machine, and I am running Snow Leopard. The other machines that are experiencing this crash are running 10.5.8. Sometimes this crash can happen heavily and repeatedly, my boss is complaining that she's had it happen like 5 times in an hour. This is a pretty big problem, hopefully a solution can be found soon.

java.lang.ThreadDeath.png

Edited by Guest
added screenshot of the error
Link to comment
Share on other sites

Are all of your users using the same Mac OS? Are you on Mac, OilCan?

What plugins do you each have installed? What versions are they?

Could you both please check your system logs in the Console and see if there are any error messages the next time you get this message?

Please email your logs and plugin information to [email protected] and I'll take a look at what is occurring.

Link to comment
Share on other sites

Hi David,

I will try to capture some console errors as soon as I can.

Users are in 10.4.11 and 10.5.8 with all other OS updates applied.

All users have the latest SC (2.744) and SM (3.33) plugins installed.

Also of note with the latest SC: Users are reporting - and I have confirmed that any layout that has a field that calls the SCGetInfo() command will beachball FileMaker for 15 seconds before allowing the next input.

For example, we have a layout that shows a list Work Orders for a job in a portal. There is a field that calls SCGetInfo() to see if there are files in the SuperContainer for that Work Order. This layout had no issues before we upgraded to the latest SC plugin (2.744). Now, the layout beachballs immediately. I had to remove the attachment indicator field from the layout - as it became unusable.

...Not sure if it's related - but it definitely coincides with the plugin update.

I've emailed the staff asking to note the error time and call me over when the 'threaddeath' error occurs. I'll grab the log info and send it over to you as soon as I can.

Thanks,

Jerremy

Link to comment
Share on other sites

"Are all of your users using the same Mac OS? Are you on Mac, OilCan?

What plugins do you each have installed? What versions are they?"

As I indicated the users that are experiencing this issue are on OS X 10.5.8. I am not experiencing the error on my machine, and I am running Snow Leopard, 10.6.3. We have recently upgraded to FM11 from FM10, though I think some users might have been experiencing this error in FM10 as well.

SuperContainer is the only plugin currently used by our system. It is the most current version, 2.744.

If it matters, the server is running OS X Server 10.5.8, FileMaker Server 10 Advanced.

Link to comment
Share on other sites

Is there any new information about what is going on here? My employers are riding me about this problem, and I can't say I blame them. If I can't get a resolution to this I may have to abandon SuperContainer for regular containers in the near future.

Link to comment
Share on other sites

I've been in contact with Jerremy, the OP for this thread, though I haven't received an email from you, as far as I've seen. I sent him a test build of the plugin which may have resolved the issue for him. If you would like to send me an email at [email protected] I can send you a copy of this test plugin as well to see if it helps your error.

Link to comment
Share on other sites

thanks for the response. I have sent you an email.

Also, I would like to mention that I have found how to conjure this error up at will on the machines running 10.5.8. It can be produced by rapidly switching between layouts with at least one of the layouts having supercontainers on them. In most cases we have more than one supercontainer on the layouts that use them, not sure if this is a pertinent detail but it might be.

Link to comment
Share on other sites

Hi all,

The test version that David sent over appears to have fixed the java.lang.threaddeath error.

It was installed on all machines on Tuesday morning, and there has not been a report of the error since.

However, we are still experiencing an issue with SCGetInfo calls. Fields on layouts that use this calc SLOW use down to a crawl, making the layout beachball.

This behavior was not present in previous versions of the the plugin.

oilcan, I'd be interested to see what happens if you install the plugin and use the technique to create the error... Hopefully this fixes the issue.

David, thanks for your help on this - but have you found anything that would lead to the slowness caused by the SCGetInfo?

Thanks,

Jerremy

Link to comment
Share on other sites

Doh. I jinxed it. Just received a call from a user that just received the error. Confirmed that they have the 'new' version of the plugin.

From the Console:

Apr 30, 2010 1:54:57 PM com.prosc.fmkit.PluginBridge doFunction

WARNING: No result in main thread AWT-AppKit for PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1}. All plugin functions should always return a result!!!

Apr 30, 2010 1:54:57 PM com.prosc.fmkit.PluginBridge doFunction

WARNING: No result in main thread AWT-AppKit for PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1}. All plugin functions should always return a result!!!

Apr 30, 2010 1:54:57 PM com.prosc.fmkit.PluginBridge doFunction

WARNING: No result in main thread AWT-AppKit for PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1}. All plugin functions should always return a result!!!

Apr 30, 2010 1:54:57 PM com.prosc.supercontainer.FileViewApplet$2 run

SEVERE: Unexpected error occurred

java.lang.ThreadDeath

at java.lang.Thread.stop(Thread.java:716)

at java.lang.ThreadGroup.stopOrSuspend(ThreadGroup.java:671)

at java.lang.ThreadGroup.stop(ThreadGroup.java:584)

at sun.awt.AppContext.dispose(AppContext.java:427)

at sun.applet.AppletClassLoader.release(AppletClassLoader.java:807)

at sun.plugin.security.PluginClassLoader.release(PluginClassLoader.java:438)

at sun.applet.AppletPanel.release(AppletPanel.java:177)

at sun.applet.AppletPanel.sendEvent(AppletPanel.java:275)

at sun.plugin.AppletViewer.onPrivateClose(AppletViewer.java:877)

at sun.plugin.AppletViewer$2.run(AppletViewer.java:826)

at java.lang.Thread.run(Thread.java:613)

The get info calls are for determining if the the record has an attachment, displayed via conditional formatting.

So, although the number of error reports from users is down, it looks like the error still exists.

Jerremy

Link to comment
Share on other sites

David:

Any updates?

Users are still reporting threaddeath errors (although less than before - now using the test 2.745 plugin).

I've also had to disable fields on layouts that use the SCGetInfo call because of the massive slowdown introduced in a recent plugin update.

This is a key feature in our system as it indicates if a SuperContainer is present.

Please - any progress?

Thanks,

Jerremy

Link to comment
Share on other sites

Yes, please (on the new plugin build).

2 more theaddeaths today...

...and I was surprised how many places in our system we were using the SCGetInfo to indicate that a SC attachment was present. I had to go through and remove them all - making our users grumpy.

Here is a typical calc:

Case(not IsEmpty(SCGetInfo( Job_Number & "/" & "Graphics" & "/" & Panel_Number & "/" & Random_SC_Link)); "YES"; "NO")

Checks the path to see if the attachment is there.

These all worked perfectly before we upgraded the plugin to the current version. Looking back at the changelog for SC, I believe the previous version we were using before 2.744 was 2.64 - so I'm not sure which version of the plugin introduced this behavior.

Thanks,

Jerremy

Link to comment
Share on other sites

  • 5 years later...

This topic is 3144 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.