Please open a bug about this in the JEP Bugs tracker, and attach one
or more full crash logs (don't just paste them into a comment, and
only attach more than one if they're significantly different from each
other).
When you open the bug, please also specify a publicly accessible URL
to test with.
I can't tell much from what you've posted here. On the face of it, it
looks like the crashes are caused by an attempt to write an invalid
string ("appletInfo") to the Console ... but that shouldn't be
possible (appletInfo should always be valid). (The crashes seems to
happen at line 663 of AppletView.m, in
Java_AppletFramePanel_tellAppletCreated().)
I've never seen this kind of crash myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the problem is that the URLs of the pages that reference our applet can contain escaped spaces (e.g. %20 for space) in them - and the URLs seem to be logged. I'm guessing NSLog() treats %n as a formatting character, and looks to substitute in the nth argument.
When we run the applet and it doesn't crash, we see (on the console) the appletInfo string truncated at the first '%'. On the Java console, we see the whole string.
Unfortunately, there is no chance of changing the URLs we use (they are effectively customer created - if they want to put a space in the name of their group, we can't stop them).
Does this seem likely?
I'm afraid at the moment, I am unable to give you a public URL.
Thanks for your help.
Steffan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I think the problem is that the URLs of the pages that reference our
> applet can contain escaped spaces (e.g. %20 for space) in them ...
> Does this seem likely?
Yes, it does. The JEP does log the URLs. I'll be looking for a
workaround.
> I'm afraid at the moment, I am unable to give you a public URL.
It'd still be nice to have one. But now that I think I understand the
problem, it's less important.
> I'll raise a bug as soon as I get a chance.
Don't bother for now. I'll let you know if I think it's necessary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not a Mac programmer, but would replacing line 663 with the following solve it?
NSLog(@"%s",appletInfo);
I'm afraid I also have a couple of follow up questions (sorry to hassle you, but I'm being pushed for the answer to these):
1. Do you currently have any plan for when the next release of JEP is likely to be (presumably including a fix for this issue)? I know we could just compile our own, but our customer is unlikely to want to install an "unofficial" version on several thousand machines.
2. Do you know what the process is for getting JEP updated in release versions of Firefox? Does each version of Firefox just pick up the latest JEP (we noticed it went up to 0.9.6 in Firefox 2.0.0.2), or does someone at Mozilla make a choice about when to upgrade the JEP version?
Thanks a lot for any help, and apologies again for hassling you about this.
Regards,
Steffan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I'm not a Mac programmer, but would replacing line 663 with the
> following solve it?
>
> NSLog(@"%s",appletInfo);
No. In fact this would cause the JEP to crash 100% of the time.
appletInfo isn't an ordinary string (it's a Unicode string, aka an
NSString * or a CFStringRef).
My solution to this problem (which I've already added to my working
version of the JEP) is to have AppletFramePanel.createApplet() add a
timestamp to the beginning of appletInfo (on the Java side), and then
use something else than a printf-derivative (on the Objective-C side)
to write the string to stdout. So there's no danger than any
accidental escape sequences will be interpreted.
The best quick fix is to comment out lines 663 and 664. But I don't
recommend rebuilding the JEP for production use unless you know what
you're doing. Building the Java parts for all platforms is
particularly tricky. And getting universal binaries is also a pain.
I can't tell you when I'll be able to release JEP 0.9.6.1. I do hope
to release it in the next couple of weeks ... but I've been saying
that for the last couple of months :-)
The Firefox release schedule also isn't definite. But they're near
the beginning of the cycle for Firefox 2.0.0.4, and I hope to get JEP
0.9.6.1 into that. Once Firefox 2.0.0.4 gets within a month of
release, you should be able to follow its progress at http://wiki.mozilla.org/Firefox.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at http://wiki.mozilla.org/Firefox:1.5.0.12-2.0.0.4, the deadline for nominations for Firefox 2.0.0.4 appears to be Friday. Is there anything I can do to make sure that this fix gets into this version?
Thanks once again for all your help.
Steffan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just released JEP 0.9.6.1, which (presumably) fixes the problem
you reported. You'll need to test it to be sure, though (since you
never gave me a URL to test with).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have now tested this on a Mac and can confirm that the whole URL appears on the console - and I therefore have confidence that the problem is fixed (obviously, I can't know for sure, as the crashing is intermittent).
I notice also that it's just been checked in to the Firefox branches.
Thanks once again for your very quick fix for this issue.
Steffan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Thanks once again for your very quick fix for this issue.
You're most welcome.
The problem was easy to fix, once I understood the cause. But the
speed with which a new version appeared (and was bundled with
non-trunk Firefox nightlies) was just luck -- both the JEP and Firefox
were at the right points in their release cycles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some (but not all) of our test Macs are crashing when loading our applet (before initialisation).
The relevant part of the firefox crash log is:
Thread 24 Crashed:
0 com.apple.CoreFoundation 0x907c29a8 _CFStringAppendFormatAndArgumentsAux + 3800
1 com.apple.CoreFoundation 0x907c1988 _CFStringCreateWithFormatAndArgumentsAux + 144
2 com.apple.Foundation 0x9296a314 NSLogv + 84
3 com.apple.Foundation 0x9296a2b0 NSLog + 28
4 JavaEmbeddingPlugin 0x05fc968c Java_AppletFramePanel_tellAppletCreated + 380
5 <<00000000>> 0x089f0264 0 + 144638564
6 <<00000000>> 0x089e9ab0 0 + 144612016
7 <<00000000>> 0x089e99c0 0 + 144611776
8 <<00000000>> 0x089e9ab0 0 + 144612016
9 <<00000000>> 0x089e9ab0 0 + 144612016
10 <<00000000>> 0x089e9e10 0 + 144612880
11 <<00000000>> 0x089e7164 0 + 144601444
12 libclient.dylib 0x9b494fc8 jio_snprintf + 398952
13 libclient.dylib 0x9b4a2564 JVM_StartThread + 2612
14 libclient.dylib 0x9b4a2450 JVM_StartThread + 2336
15 libclient.dylib 0x9b4a23e0 JVM_StartThread + 2224
16 libclient.dylib 0x9b4a229c JVM_StartThread + 1900
17 libclient.dylib 0x9b42cfac JNI_CreateJavaVM_Impl + 48844
18 libSystem.B.dylib 0x9002b508 _pthread_body + 96
Any ideas?
Thanks.
Steffan
Please open a bug about this in the JEP Bugs tracker, and attach one
or more full crash logs (don't just paste them into a comment, and
only attach more than one if they're significantly different from each
other).
When you open the bug, please also specify a publicly accessible URL
to test with.
I can't tell much from what you've posted here. On the face of it, it
looks like the crashes are caused by an attempt to write an invalid
string ("appletInfo") to the Console ... but that shouldn't be
possible (appletInfo should always be valid). (The crashes seems to
happen at line 663 of AppletView.m, in
Java_AppletFramePanel_tellAppletCreated().)
I've never seen this kind of crash myself.
Hi,
I'll raise a bug as soon as I get a chance.
I think the problem is that the URLs of the pages that reference our applet can contain escaped spaces (e.g. %20 for space) in them - and the URLs seem to be logged. I'm guessing NSLog() treats %n as a formatting character, and looks to substitute in the nth argument.
When we run the applet and it doesn't crash, we see (on the console) the appletInfo string truncated at the first '%'. On the Java console, we see the whole string.
Unfortunately, there is no chance of changing the URLs we use (they are effectively customer created - if they want to put a space in the name of their group, we can't stop them).
Does this seem likely?
I'm afraid at the moment, I am unable to give you a public URL.
Thanks for your help.
Steffan
> I think the problem is that the URLs of the pages that reference our
> applet can contain escaped spaces (e.g. %20 for space) in them ...
> Does this seem likely?
Yes, it does. The JEP does log the URLs. I'll be looking for a
workaround.
> I'm afraid at the moment, I am unable to give you a public URL.
It'd still be nice to have one. But now that I think I understand the
problem, it's less important.
> I'll raise a bug as soon as I get a chance.
Don't bother for now. I'll let you know if I think it's necessary.
Hi Steven,
I'm not a Mac programmer, but would replacing line 663 with the following solve it?
NSLog(@"%s",appletInfo);
I'm afraid I also have a couple of follow up questions (sorry to hassle you, but I'm being pushed for the answer to these):
1. Do you currently have any plan for when the next release of JEP is likely to be (presumably including a fix for this issue)? I know we could just compile our own, but our customer is unlikely to want to install an "unofficial" version on several thousand machines.
2. Do you know what the process is for getting JEP updated in release versions of Firefox? Does each version of Firefox just pick up the latest JEP (we noticed it went up to 0.9.6 in Firefox 2.0.0.2), or does someone at Mozilla make a choice about when to upgrade the JEP version?
Thanks a lot for any help, and apologies again for hassling you about this.
Regards,
Steffan
> I'm not a Mac programmer, but would replacing line 663 with the
> following solve it?
>
> NSLog(@"%s",appletInfo);
No. In fact this would cause the JEP to crash 100% of the time.
appletInfo isn't an ordinary string (it's a Unicode string, aka an
NSString * or a CFStringRef).
My solution to this problem (which I've already added to my working
version of the JEP) is to have AppletFramePanel.createApplet() add a
timestamp to the beginning of appletInfo (on the Java side), and then
use something else than a printf-derivative (on the Objective-C side)
to write the string to stdout. So there's no danger than any
accidental escape sequences will be interpreted.
The best quick fix is to comment out lines 663 and 664. But I don't
recommend rebuilding the JEP for production use unless you know what
you're doing. Building the Java parts for all platforms is
particularly tricky. And getting universal binaries is also a pain.
I can't tell you when I'll be able to release JEP 0.9.6.1. I do hope
to release it in the next couple of weeks ... but I've been saying
that for the last couple of months :-)
The Firefox release schedule also isn't definite. But they're near
the beginning of the cycle for Firefox 2.0.0.4, and I hope to get JEP
0.9.6.1 into that. Once Firefox 2.0.0.4 gets within a month of
release, you should be able to follow its progress at
http://wiki.mozilla.org/Firefox.
Thanks a lot.
Steffan
Looking at http://wiki.mozilla.org/Firefox:1.5.0.12-2.0.0.4, the deadline for nominations for Firefox 2.0.0.4 appears to be Friday. Is there anything I can do to make sure that this fix gets into this version?
Thanks once again for all your help.
Steffan
> Is there anything I can do to make sure that this fix gets into this
> version?
No. But I hope to release JEP 0.9.6.1 today or tomorrow.
I've just released JEP 0.9.6.1, which (presumably) fixes the problem
you reported. You'll need to test it to be sure, though (since you
never gave me a URL to test with).
I have now tested this on a Mac and can confirm that the whole URL appears on the console - and I therefore have confidence that the problem is fixed (obviously, I can't know for sure, as the crashing is intermittent).
I notice also that it's just been checked in to the Firefox branches.
Thanks once again for your very quick fix for this issue.
Steffan
> Thanks once again for your very quick fix for this issue.
You're most welcome.
The problem was easy to fix, once I understood the cause. But the
speed with which a new version appeared (and was bundled with
non-trunk Firefox nightlies) was just luck -- both the JEP and Firefox
were at the right points in their release cycles.