Solved OpenJDK v1.7 core dump in port: /devel/arduino when uploading...

J

JamesElstone

Hi All,

Firstly, not sure if this is the right section of this forum to be posting, so please excuse me if this is wrong.

I am running version 1.0.6 of the devel/arduino port. The IDE starts OK, compiles a sketch, but on uploading I get a Java core dump.

GDB backtrace shows the following:
Code: 
(gdb) backtrace
#0  0x281bbd33 in nanosleep () from /lib/libc.so.7
#1  0x281bb832 in usleep () from /lib/libc.so.7
#2  0x2809267f in usleep () from /lib/libthr.so.3
#3  0x3fbd8010 in drain_loop (arg=0xbf550a38) at /usr/ports/comms/rxtx/work/rxtx-2.2pre2/./src/SerialImp.c:1296
Using avr-dude is fine standalone, and works well. I have the latest version of comms/rxtx installed and have created static links for /usr/local/arduino/lib/librxtxSerial.so and /usr/local/arduino/lib/RXTXcomm.jar to /usr/local/openjdk/jre/lib/i386/librxtxSerial.so and /usr/local/openjdk/jre/lib/ext/RXTXcomm.jar respectively.

I have tried using RXTXcomm.jar and librxtxSerial.so files from both the Arduino port and the rxtx port, but both versions result in a core dump.

EDIT: I have removed Linux Compatability from my kernel, so this issue is not emulation based.

I am beginning to think that this issue is potentially with my base system, rather than the arduino port...

I would really like a bit of help here!

Does any body have any ideas how to investigate, debug or have any ideas to solving this issue please? A bit of debugging guidance would be welcomed please!

Is anybody else successfully using the Arduino IDE v1.0.6 in FreeBSD 10.1 to upload sketches?

Also if I wanted to rebuild all items on the critical path, is /lib/libc.so.7 part of kernel world, libtools, or something else?

Thanks in advance,

James
 
JamesElstone said:
Hi All,

Firstly, not sure if this is the right section of this forum to be posting, so please excuse me if this is wrong.

I am running version 1.0.6 of the devel/arduino port. The IDE starts OK, compiles a sketch, but on uploading I get a Java core dump.

I am beginning to think that this issue is potentially with my base system, rather than the arduino port...
James
Click to expand...
The problem seems to be the OS version, openjdk7, or rxtx. It does not appear to be related to the code in the port.
System A: laptop i386 Intel processor 2 cores
System B: desktop/server i386 Intel processor 4 virtual cores
Code: 
System             FreeBSD               Java          Arduino  Works?
A           9.1-RELEASE openjdk6  1.0.4       OK
A           9.1-RELEASE openjdk6  1.0.5       OK
A           9.1-RELEASE openjdk6  1.0.6       OK
A          10.1-RELEASE openjdk7  1.0.6        Abort trap
A          10.1-RELEASE openjdk7  1.0.6,1     Abort trap
B          10.0-RELEASE openjdk6  1.0.5       OK
B          10.0-RELEASE openjdk6  1.0.6       OK
B          10.0-RELEASE openjdk6  1.0.6,1    OK
The suspects seem to be FreeBSD 10.1 (vs. 10.0 or 9.1), openjdk7 (vs. openjdk6), and rxtx.
My suspect is rxtx (which in the past has been cranky) or the combination of openjdk7/rxtx.
Since the ports/packages seem to be in major disarray (many times the port installs but the packages don't, or vice versa), I tried combinations of installing openjdk7 from ports or packages, no differences found. I tried installing openjdk6 on System A and getting 'arduino' to use it, but that failed due to missing libraries.
 
For whatever it's worth, I got this to work by using the RXTX-2.2pre2 version of RXTXcomm.jar (the current version) and the librxtxSerial-2.1-7.so.0 file from an older version. You need to re-point the symlink librxtxSerial.so at librxtxSerial-2.1-7.so.0 .

The hard part of this thing is ignoring the RXTX version mismatch warning it spits out when you start arduino. But I've been able to upload sketches successfully.

I would have uploaded the file but the forum doesn't like the extension. And it's right: passing around executable binary files and shared libraries can spread viruses.

I still haven't been able to determine which thread is crashing and what exactly it did to crash.
 
Hi,

After spending nearly 40 hours on this I have fixed the problem in the RXTX port and have a set of patch files which resolves the core dump and a whole host of other issues in RXTX on FreeBSD as well as making a few things a bit easier:
  • Fixed Java Core Dump on RXTX port close and and initial testing performed during port detection initiation.
  • The driver being initiated three times on startup (leads to long load time),
  • Enabled debug std out from Java command line,
  • Correct loading of RXTX properties if multiple Java library class paths exist on host,
  • All unterminated strings in debug output leading to corruption of debug output on the second enumeration,
  • Correct ports detected for FreeBSD between <9.0 and >10.0,
  • Allow parallel port skipping from Java command line for instances of RXTX hosts that don't use lpt functionality,
  • Put code layout under standard formatting so it is easier for the next person to read certain sections.
So this is 2.2pre2 plus a patch.

I also have a small patch for the Arduino port which removes the "pde / ino" error on startup and allows you to load sketches into the IDE as the main code base expects and supports.

Just going to work out how to submit this back into the ports tree, so it can be shared by all...

Will keep all posted!!
 
Have submitted PRs for the maintainers to review (with juice patches attached):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200179
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200178
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200177

The above changes also resolve:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195123
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196892
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128809

Now it is a matter of waiting for the port maintainers to respond, and the bug system to follow its process!

Kr,

James.
 
You must log in or register to reply here.
Back
Top