RHS function crashes Java in 9.3.2

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Import the attached Eclipse project (TestBug) into your workspace.
2. Add sml.jar and soar-debugger.jar to your build path (use 9.3.2 
distribution).
3. Also have Soar-9.3.2/bin on your path (you probably already do).
4. Run TestBug.java.
5. When the Soar debugger opens, trying stepping once or twice.
6. Redo the configuration using 9.3.1 stuff instead; this time, Java doesn't 
crash.

What is the expected output? What do you see instead?
I expect the debugger to step once or twice. Instead, Java crashes.

What version of the product are you using? On what operating system?
Using Soar 9.3.2, Windows 7 64-bit.

Please provide any additional information below.
The original problem happened in bigger system (XNL-Soar). It would only occur 
when we opened the debugger (using the same method as in the attached project), 
and the behavior would change if the RHS function returned an empty string 
instead. Returning just an empty string, sometimes Java would crash as soon as 
the function was encountered, other times it would crash as soon as the 
debugger was closed, other times not at all.

When the original problem happened (using XNL-Soar), Java printed out a 
diagnostic, and I'm attaching this, too.

Original issue reported on code.google.com by garfield...@gmail.com on 31 Oct 2012 at 10:36

Attachments:

• TestBug.zip
• hs_err_pid118236.log

[GoogleCodeExporter]

For what it's worth, I wasn't able to reproduce the crash on a 64-bit Ubuntu 
computer using java 1.7.0. I also wasn't running in Eclipse, but I don't think 
that would matter. Now that I read your error log, the crash seems to be 
specific to Windows. I'll try this again when I have access to a Windows 
machine.

Original comment by joseph...@gmail.com on 2 Nov 2012 at 7:56

[GoogleCodeExporter]

I've tested this on Windows 7 64-bit, and managed to reproduce the crash using 
the 9.3.2 release. I also tried running your code with libraries I compiled 
from a recent subversion checkout, and didn't get the crash. So somewhere 
between the last release and now we inadvertently fixed the bug. The solution 
then is to check out the source code from subversion and build your own 
libraries. You can find instructions for this on the wiki.

Original comment by joseph...@gmail.com on 3 Nov 2012 at 12:25

• Changed state: Fixed

[GoogleCodeExporter]

Thanks!
Just to be clear, my own reproduction of the problem was spotty at times, so 
unless the source of the bug is found, there may be a chance that that it's 
still there. Tracking it down at this point (with bisect or some such) is 
probably too much work.

Original comment by garfield...@gmail.com on 3 Nov 2012 at 1:09