Forums > Java

recent java crashes…


jbm
May 7, 2007 | 1:59 pm

Does anything in this crashed thread look informative to anybody?

The conditions leading to the crash can vary a little, but the crashed thread always shows "dyld_stub__keymgr_get_and_lock_processwide_ptr" as its last entry.

Thread 6 Crashed:
0 libjvm.dylib 0x9cc49b44 dyld_stub__keymgr_get_and_lock_processwide_ptr + 211844
1 libjvm.dylib 0x9cc49ae0 dyld_stub__keymgr_get_and_lock_processwide_ptr + 211744
2 libjvm.dylib 0x9ca3f2e8 JVM_GetCPFieldSignatureUTF + 33168
3 libjvm.dylib 0x9cac0b2c JVM_OnExit + 191384
4 libjvm.dylib 0x9cac09d0 JVM_OnExit + 191036
5 libjvm.dylib 0x9ca3e5d0 JVM_GetCPFieldSignatureUTF + 29816
6 libjvm.dylib 0x9ca3e284 JVM_GetCPFieldSignatureUTF + 28972
7 libjvm.dylib 0x9cc41c78 dyld_stub__keymgr_get_and_lock_processwide_ptr + 179384
8 libjvm.dylib 0x9ca3e0a0 JVM_GetCPFieldSignatureUTF + 28488
9 libjvm.dylib 0x9caad954 JVM_OnExit + 113088
10 libjvm.dylib 0x9caad2e0 JVM_OnExit + 111436
11 libjvm.dylib 0x9ca3de68 JVM_GetCPFieldSignatureUTF + 27920
12 libjvm.dylib 0x9ca3dd88 JVM_GetCPFieldSignatureUTF + 27696
13 libjvm.dylib 0x9cacb708 JVM_OnExit + 235380
14 libjvm.dylib 0x9ca3a4bc JVM_GetCPFieldSignatureUTF + 13156
15 libjvm.dylib 0x9cc52c0c dyld_stub__keymgr_get_and_lock_processwide_ptr + 248908
16 libjvm.dylib 0x9cc0c834 JVM_RaiseSignal + 764784
17 libjvm.dylib 0x9c94088c JNI_CreateJavaVM_Impl + 43984
18 libSystem.B.dylib 0x9002bc28 _pthread_body + 96



jbm
May 7, 2007 | 2:13 pm

hmm… It seems like I can avoid the crash by skipping a Collection.sort() step in my code… I’ve checked my equals() and compareTo() and they seem fine to me, but I’m admittedly shakey on the Comparable interface:

public boolean equals(Object o)
{
if (!(o instanceof Allusion))
return false;
Allusion n = (Allusion)o;
return n.Score.equals(Score) && n.Type.equals(Type);
}

public int compareTo(Allusion n)
{
int lastCmp = Score.compareTo(n.Score);
return (lastCmp != 0 ? lastCmp : Type.compareTo(n.Type));
}

An "Allusion" is a musical pattern which has been found to match another pattern, which I call a "VoiceSegment", to a certain degree of accuracy. The "Score" is a value of the accuracy of the match, while the "Type" is the general category of the match. I’m storing all of a VoiceSegment’s Allusions in an ArrayList, then sorting the list. Without the sort it seems okay, but with the sort it crashes…

I should mention, too, that it seems stable when it’s dealing with smaller amounts of data (shorter midi files to analyze), but with large data sets it crashes.

J.


May 7, 2007 | 2:24 pm

jbmaxwell wrote:
> hmm… It seems like I can avoid the crash by skipping a
> Collection.sort() step in my code… I’ve checked my equals() and
> compareTo() and they seem fine to me, but I’m admittedly shakey on
> the Comparable interface:

Well, a sort() shouldn’t cause a JVM crash – in fact, nothing (ideally)
should cause a JVM crash! Which JVM are you using? (1.5? 1.4?) If you
are in a position to try changing, say back to 1.4, do matters improve?
Have you done an OS update recently?

This would seem like an Apple bug (a quick google suggests that you’re
not the only one to have had this problem, but didn’t throw up any
immediately obvious solutions).


O



jbm
May 7, 2007 | 2:36 pm

Thanks, Owen.

Well, although an Apple bug would be sort of personally comforting, it would be a real bummer to my project. I’m using 1.5, but my code is loaded with generics, so I don’t know how simple it would be to go back to 1.4. Does the JVM itself care about generics, if the classes are already compiled?

J.


May 7, 2007 | 2:58 pm

I think the bytecode format is different for 1.4 and 1.5, which would
make life awkward.

Some things to try:
- Any steps towards reproducibility; presumeably merely sorting a
Collection isn’t enough on its own, so whatever context you can add will
be valuable.

- Trawl some Java fora and newsgroups (comp.lang.java, or something) and
see if you can find any other reports of this type of crash.

- Talk to someone at Apple (maybe with a post to whatever Java forum
they have available).

What’s your status re: OS updates, Java updates etc.?


O

jbmaxwell wrote:
> Thanks, Owen.
>
> Well, although an Apple bug would be sort of personally comforting,
> it would be a real bummer to my project. I’m using 1.5, but my code
> is loaded with generics, so I don’t know how simple it would be to go
> back to 1.4. Does the JVM itself care about generics, if the classes
> are already compiled?
>
> J. _______________________________________________ java-dev mailing
>



jbm
May 7, 2007 | 3:51 pm

> What’s your status re: OS updates, Java updates etc.?
>

I managed to get my system running audio reasonably well a few months ago by wiping and reverting from 10.4.8 to 10.4.7, so I haven’t dared to update since then. I haven’t done the last java update, as it claims to be for 10.4.8 only. I could brave a (combo) update to 10.4.9, but it’s scaaaaary… oooh…

As far as reproducing it, the issue is just with longer midi files. The pattern matcher is running a *lot* of tests, and with smaller/shorter files it seems fine, but when the file gets long the crashes start. I had the max in the jvm options at:

max.jvm.option -Xmx512m

…so I don’t think it should be a memory problem… But it does kind of seem that way. Perhaps I’ll try assigning some obscene amount of memory to the jvm, just for kicks.

thanks again.

J.



jbm
May 10, 2007 | 7:42 pm

After doing some housework on my code, and getting rid of some heavy post()ing, I finally avoided the crash, and got an error from Max:

? error: java.lang.AbstractMethodError: com.cycling74.max.Atom.equals(Ljava/lang/Object;)Z
? error: at kompose.Allusion.equals(Allusion.java:57)

This relates to an equals() in my class:

public boolean equals(Object o)
{
if (!(o instanceof Allusion))
return false;
Allusion n = (Allusion)o;
return n.Score.equals(Score) && n.Type.equals(Type);
}

Specifically, line 57 from the error is the return statement. In the class, "Score" is an Atom(double) and Type is an Atom(String). Is there an obvious problem with using those two, or with the way I’m using them?

J.


May 10, 2007 | 9:13 pm

The error indicates that the problem is in Atom’s equals method.
Maybe line 57 is actually the return n.Score.blahblah line? Are you
sure Max is finding the class you think it is? I don’t see anything
obviously wrong with your code.

Ben


May 10, 2007 | 9:26 pm

I don’t know if Atom has an equals method of the top of my head.
It would make sense to me to make Score just a double and Type
a String as opposed to Atoms and do it like:

> (n.Score == this.Score && n.Type.equals(this.Type)

just my 2 cents.

t

On May 10, 2007, at 12:42 PM, jbmaxwell wrote:

>
> After doing some housework on my code, and getting rid of some
> heavy post()ing, I finally avoided the crash, and got an error from
> Max:
>
> ? error: java.lang.AbstractMethodError:
> com.cycling74.max.Atom.equals(Ljava/lang/Object;)Z
> ? error: at kompose.Allusion.equals(Allusion.java:57)
>
> This relates to an equals() in my class:
>
> public boolean equals(Object o)
> {
> if (!(o instanceof Allusion))
> return false;
> Allusion n = (Allusion)o;
> return n.Score.equals(Score) && n.Type.equals(Type);
> }
>
> Specifically, line 57 from the error is the return statement. In
> the class, "Score" is an Atom(double) and Type is an Atom(String).
> Is there an obvious problem with using those two, or with the way
> I’m using them?
>
> J.


May 10, 2007 | 10:06 pm

Atom does indeed have an equals method. It’s an abstract method
that’s implemented by each of the three possible Atom subclasses
(FloatAtom, StringAtom, and IntAtom).

Ben



jbm
May 10, 2007 | 10:50 pm

Yeah, I had used Atom.equals() before, apparently without issue… But I may try pulling out the double and String, just to see.

"The error indicates that the problem is in Atom’s equals method.
Maybe line 57 is actually the return n.Score.blahblah line? Are you
sure Max is finding the class you think it is? I don’t see anything
obviously wrong with your code."

Yes, line 57 is the return, and I can’t see, off the top of my head, how Max could be finding anything else. But I’ll look into that. What’s really strange is that the crash only shows up with larger/longer midi files. But there’s nothing in the code that should really change with larger files – just more of same.

Thanks for your help. If anything else occurs to you, please let me know.

J.



jbm
May 15, 2007 | 9:23 am

I’m still having the same crashes when trying to analyze longer midi files. I’ve looked more into the crash, and noticed that the Java crash log isn’t recording it, which seems to suggest that, although it’s only mxj that’s running when the crash occurs, it may not specifically be a crash within the jvm. But I don’t know if that really makes sense…

Anyway, what I’m wondering is whether this somehow has something to do with mxj, in a more general sense. Not that I’m thinking there’s a bug in mxj, but simply that perhaps Max is doing something I don’t know about. For example, is there any chance that Max’s stack would somehow be affected by a long, tedious, and memory-intensive java routine running in mxj? Nothing is happening in Max during this routine, so Max won’t be dealing stacking up any events – it just spins its little ball. But is there any situation in which Max or mxj might get cranky about being made to wait, as it were?

The other thing I’m wondering, which is sort of related to this last question, is whether putting this routine is a separate thread would help? Does a new thread launched in mxj have any greater independence from Max than the main mxj thread?

As you see, I’m generally unclear about the relationship between Max, mxj, and the jvm at runtime…

Thanks in advance for any clarification.

J.


May 15, 2007 | 6:35 pm

Anything is possible. If you suspect that the mxj obj is the problem,
one thing you could try to verify this is to adapt your code so that
it runs from the command line. Either it crashes there or it doesn’t,
and either way you’ll learn something. :)

Ben

On 5/15/07, jbmaxwell wrote:
>
> I’m still having the same crashes when trying to analyze longer midi files. I’ve looked more into the crash, and noticed that the Java crash log isn’t recording it, which seems to suggest that, although it’s only mxj that’s running when the crash occurs, it may not specifically be a crash within the jvm. But I don’t know if that really makes sense…
>
> Anyway, what I’m wondering is whether this somehow has something to do with mxj, in a more general sense. Not that I’m thinking there’s a bug in mxj, but simply that perhaps Max is doing something I don’t know about. For example, is there any chance that Max’s stack would somehow be affected by a long, tedious, and memory-intensive java routine running in mxj? Nothing is happening in Max during this routine, so Max won’t be dealing stacking up any events – it just spins its little ball. But is there any situation in which Max or mxj might get cranky about being made to wait, as it were?
>
> The other thing I’m wondering, which is sort of related to this last question, is whether putting this routine is a separate thread would help? Does a new thread launched in mxj have any greater independence from Max than the main mxj thread?
>
> As you see, I’m generally unclear about the relationship between Max, mxj, and the jvm at runtime…
>
> Thanks in advance for any clarification.
>
> J.
>


May 15, 2007 | 7:06 pm

also…if you can somehow make it reproducible that would be good.
if i am doing some pretty intensive java stuff i usually end up doing it
in its own thread as to not gum up the scheduler or main app loop.
t

On May 15, 2007, at 11:35 AM, Ben Nevile wrote:

> Anything is possible. If you suspect that the mxj obj is the problem,
> one thing you could try to verify this is to adapt your code so that
> it runs from the command line. Either it crashes there or it doesn’t,
> and either way you’ll learn something. :)
>
> Ben
>
> On 5/15/07, jbmaxwell wrote:
>>
>> I’m still having the same crashes when trying to analyze longer
>> midi files. I’ve looked more into the crash, and noticed that the
>> Java crash log isn’t recording it, which seems to suggest that,
>> although it’s only mxj that’s running when the crash occurs, it
>> may not specifically be a crash within the jvm. But I don’t know
>> if that really makes sense…
>>
>> Anyway, what I’m wondering is whether this somehow has something
>> to do with mxj, in a more general sense. Not that I’m thinking
>> there’s a bug in mxj, but simply that perhaps Max is doing
>> something I don’t know about. For example, is there any chance
>> that Max’s stack would somehow be affected by a long, tedious, and
>> memory-intensive java routine running in mxj? Nothing is happening
>> in Max during this routine, so Max won’t be dealing stacking up
>> any events – it just spins its little ball. But is there any
>> situation in which Max or mxj might get cranky about being made to
>> wait, as it were?
>>
>> The other thing I’m wondering, which is sort of related to this
>> last question, is whether putting this routine is a separate
>> thread would help? Does a new thread launched in mxj have any
>> greater independence from Max than the main mxj thread?
>>
>> As you see, I’m generally unclear about the relationship between
>> Max, mxj, and the jvm at runtime…
>>
>> Thanks in advance for any clarification.
>>
>> J.
>>



jbm
May 15, 2007 | 7:35 pm

Thanks guys.

I managed to make it more stable by putting the big pattern matcher (the routine that was crashing) into its own thread. There it seems a lot happier, but not perfect. I messed around for a while trying to get it to run in Eclipse, rather than Max… But, alas, I couldn’t get it to work. I’ve never used java outside max and mxj, so I’ve got a lot to learn in terms of getting things running in the outside world.

If I can’t find anything obvious in the source, I’ll take another crack at a command-line version.

cheers,

J.



jbm
May 16, 2007 | 6:40 pm

I figure I might as well keep all my recent freakouts in one thread…

I’ve got another recent problem with an error popping up when loading my saved files (saved database files from mxj). It’s an io.InvalidClassException, which is claiming that it is "unable to create an instance" of one of my classes. The class is Serializable, and has a UID. Stanger still, the error only comes up with certain files. Even stranger, it only comes up with files generated from analyzing long midi files… Yes, if you’ve been following my recent madness, this is oddly like my problems with my pattern matcher, which crashes Max with long files, but runs fine with short ones. So, I’ve got two unexplained bugs which both seem reproducible with long midi files, but avoidable with short midi files.

Now, considering that nobody knows what the hell I’m actually doing, and posting the whole patcher, or java source would be like posting "Infinite Jest" (well, at least a few chapters), is there anything in this apparent dependence on *scale* that triggers any ideas?

Any and all thoughts greatly appreciated – the madness has reflexively turned my ‘water’ blue.

J.



jbm
May 16, 2007 | 8:01 pm

…I’m getting deeply curious about all this…

Launch Max.
Load short midi file -> fine.
Save short database file -> fine.
Load short database file -> fine.

Load long midi file -> fine.
Save long database file -> fine.
Load long database file -> fine.

Quit Max and relaunch.
Load long database file -> error "unable to create instance"
Load short database file -> fine.

Quit Max and relaunch.
Load short database file -> fine.
Load long database file -> fine.

—————–

Load short database file, run pattern matcher -> fine.
Load long database file, run pattern matcher -> crash Max.

—————–

This all just seems really odd to me. What’s up with the size thing? I’ve assigned monstrous memory to the jvm, but I don’t think that’s it. Something is changing in some fundamental way, as a result of scale alone. I’m wondering about a poor choice of datatype somewhere… Does that sound possible?

Sorry to be a pest, but this is driving me mental.

J.


May 16, 2007 | 8:21 pm

what are you using to read the midi files?
is it based on the midiparty code i posted a while ago or is it
something else?
t

On May 16, 2007, at 13:01 PM, jbmaxwell wrote:

>
> …I’m getting deeply curious about all this…
>
> Launch Max.
> Load short midi file -> fine.
> Save short database file -> fine.
> Load short database file -> fine.
>
> Load long midi file -> fine.
> Save long database file -> fine.
> Load long database file -> fine.
>
> Quit Max and relaunch.
> Load long database file -> error "unable to create instance"
> Load short database file -> fine.
>
> Quit Max and relaunch.
> Load short database file -> fine.
> Load long database file -> fine.
>
> —————–
>
> Load short database file, run pattern matcher -> fine.
> Load long database file, run pattern matcher -> crash Max.
>
> —————–
>
> This all just seems really odd to me. What’s up with the size
> thing? I’ve assigned monstrous memory to the jvm, but I don’t think
> that’s it. Something is changing in some fundamental way, as a
> result of scale alone. I’m wondering about a poor choice of
> datatype somewhere… Does that sound possible?
>
> Sorry to be a pest, but this is driving me mental.
>
> J.


May 16, 2007 | 8:51 pm

also,
it might make sense to just post your java code or at least send it
to ben or myself
and we could at least eyeball it.
t

On May 16, 2007, at 13:01 PM, jbmaxwell wrote:

>
> …I’m getting deeply curious about all this…
>
> Launch Max.
> Load short midi file -> fine.
> Save short database file -> fine.
> Load short database file -> fine.
>
> Load long midi file -> fine.
> Save long database file -> fine.
> Load long database file -> fine.
>
> Quit Max and relaunch.
> Load long database file -> error "unable to create instance"
> Load short database file -> fine.
>
> Quit Max and relaunch.
> Load short database file -> fine.
> Load long database file -> fine.
>
> —————–
>
> Load short database file, run pattern matcher -> fine.
> Load long database file, run pattern matcher -> crash Max.
>
> —————–
>
> This all just seems really odd to me. What’s up with the size
> thing? I’ve assigned monstrous memory to the jvm, but I don’t think
> that’s it. Something is changing in some fundamental way, as a
> result of scale alone. I’m wondering about a poor choice of
> datatype somewhere… Does that sound possible?
>
> Sorry to be a pest, but this is driving me mental.
>
> J.


May 16, 2007 | 9:49 pm

Have you tried printing the results of
Runtime.getRuntime().freeMemory()
Runtime.getRuntime().totalMemory()
Runtime.getRuntime().maxMemory()
to the Max window to make sure things are doing what you think
they’re doing in terms of memory?

On 16 May 2007, at 21:51, topher lafata wrote:

> also,
> it might make sense to just post your java code or at least send it
> to ben or myself
> and we could at least eyeball it.
> t
>
> On May 16, 2007, at 13:01 PM, jbmaxwell wrote:
>
>>
>> …I’m getting deeply curious about all this…
>>
>> Launch Max.
>> Load short midi file -> fine.
>> Save short database file -> fine.
>> Load short database file -> fine.
>>
>> Load long midi file -> fine.
>> Save long database file -> fine.
>> Load long database file -> fine.
>>
>> Quit Max and relaunch.
>> Load long database file -> error "unable to create instance"
>> Load short database file -> fine.
>>
>> Quit Max and relaunch.
>> Load short database file -> fine.
>> Load long database file -> fine.
>>
>> —————–
>>
>> Load short database file, run pattern matcher -> fine.
>> Load long database file, run pattern matcher -> crash Max.
>>
>> —————–
>>
>> This all just seems really odd to me. What’s up with the size
>> thing? I’ve assigned monstrous memory to the jvm, but I don’t
>> think that’s it. Something is changing in some fundamental way, as
>> a result of scale alone. I’m wondering about a poor choice of
>> datatype somewhere… Does that sound possible?
>>
>> Sorry to be a pest, but this is driving me mental.
>>
>> J.
>



jbm
May 16, 2007 | 10:00 pm

Quote: Ollie Bown wrote on Wed, 16 May 2007 22:49
—————————————————-
> Have you tried printing the results of
> Runtime.getRuntime().freeMemory()
> Runtime.getRuntime().totalMemory()
> Runtime.getRuntime().maxMemory()
> to the Max window to make sure things are doing what you think
> they’re doing in terms of memory?
>

hmmm… No, didn’t know about those! Will try that for sure.

thanks,

J.

——————-
Topher,

I’m trying to clean things up a bit, so I can perhaps send you some of this thing – it’s definitely pretty cryptic looking…
But as a little treat, I’ve (stupidly, I guess) been running Eclipse on the standard path in Max, and ignorantly hit "clean"… Well, it cleaned all of the compiled classes in my c74 folder into obvlivion. Cool!


May 16, 2007 | 10:12 pm

> Well, it cleaned all of the compiled classes in my c74 folder into
> obvlivion. Cool!

i guess that is one way to go about it!


Viewing 22 posts - 1 through 22 (of 22 total)