If it's really crashing in "didEventOccur", that function does very little -- only accesses a couple of member variables and return a value. I can't imagine how the object pointer itself got corrupted. - Cory
On 6/1/07, David Gay <[EMAIL PROTECTED]> wrote:
On 6/1/07, Philip Levis <[EMAIL PROTECTED]> wrote: > 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 > > 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. The standard javacomm was also limited (especially on Linux) and buggy, and stayed that way for years. Don't know if it's improved... David Gay _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
