Philip Levis a écrit : > On Jun 1, 2007, at 9:52 AM, Ákos Maróy wrote: > >> Ákos Maróy wrote: >>> 1XHEXCPMODULE Module: /opt/ibm-jdk-bin-1.5.0.3/jre/bin/libtoscomm.so >>> 1XHEXCPMODULE Module_base_address: 00002AAAAACD2000 >>> 1XHEXCPMODULE Symbol: >>> Java_net_tinyos_comm_TOSCommJNI_NativeSerial_1didEventOccur >> >> basically the code segfaults in the NativeSerial::didEventOccur() call. >> >> if I just put a std::cerr << "hello" << std::endl; call into the >> function - it doesn't segfault. this suggest that there's some memory >> corruption going on here. >> >> and still, it doesn't segfualt, but the mote sill stops sending data >> 1) emerges fine >> 2) do NOT pass collision tests: >> >> * checking 35 files for package collisions >> existing file /usr/share/locale/es/LC_TIME is not owned by this package >> * spent 0.0441048145294 seconds checking for file collisions >> * This package is blocked because it wants to overwrite >> * files belonging to other packages (see messages above). >> * If you have no clue what this is all about report it >> * as a bug for this package on http://bugs.gentoo.org >> >> package app-shells/ksh-93.20060214-r1 NOT merged >> through the serial port (the TX light stops to blink), and won't react >> on the data received either. it sort of hangs. >> >> >> is there a way to use standard javacomm instead of this special library >> to do the serial communication? > > Can you get it to dump core and figure our where the bug occurs? That > is, the line of code/memory access? > > With a little bit of tweaking, it shouldn't be too difficult to get > the java code working with the standard Java comm. We moved away from > it due to some issues with supporting newer versions of Linux. There > was a time when it was really hard to find. > > Phil Hi, you may be interested in this report i made some time ago, with stack trace ... http://sourceforge.net/tracker/index.php?func=detail&aid=1606811&group_id=28656&atid=393934 (the report is a bit confusing, there is actually 2 different problems exposed ) IIRC (not sure), i tracked it back to some known regression of gcc 4.1.x ... it works fine with gcc-3.x there is also "kind of" patch there : https://naurel.org/svn/tinyos-2-overlay/dev-tinyos/tinyos-tools/files/TOSComm_wrap.cxx.racecondition.patch basically if you uncomment the "if(..) ; printf ... " stuff you will see that the pointer arg1 is null quite often
Aurélien _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
